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StTMMRRY. 



This report covers the design of an intelligent Winchester Disk 
Controller. In contrast with traditional controller designs, 
the Disk Operating System, generally resident at the Host 
computer, is integrated in the controller. 

After an introduction concerning the chaxact eristics and appli- 
cations of Winchester drives, the problems involved with inter- 
facing these drives to a host computer are discussed . 
Chapter three presents the general concept which lead to the 
final design . A separation is made between hard- and software . 
The hardware consists of a Winchester Controller Module, rather 
than a random logic circuit, a processor system consisting of a 
16 bit CPU and an lOP co-processor, buffer- and program memosry 
and em interface to the Host computer. 

Chapter five deals with the software involved in this project, 
in particular the Disk Operating Systems. The UNIX operating 
system was taken as a guide-line for this purpose. 
Though no prototype was built and tested, some conclusions are 
drawn in the last chapter concerning the feasibility of the 
design and its advantages over traditional controller designs . 
In addition, some recommendations for follow-up are made. 
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Chapter 1. INTRODUCTION. 



1.1. Mass storage devices. 

Any user of a digital computer system will agree to the impor- 
tance o£ a reliable and fast ma^s storage device. This back- 
ground memory is generally used to store user programs and 
operating data in quantities too large to be kept in the compu- 
ters core memory. E>emands imposed on such storage devices are; 

- Reliability, to ensure the correct retrieval of 
stored information. 

- Speed, to minimize delays caused by data access on 
the device . 

- Cost-efficiency, meaning the price per unit of stored 
information should be as low as possible, typically far 
below the cost of a unit in core memory. 

As these requirements are to some extent contradictory, several 
compromises were made by storage device manufacturers . 

Three important kinds of storage devices can be discerned, all 
of them based on magnetic storage techniques : 

1 . Disk drives . 

2 . Dr\un devices . 

3. Tape units. 

The first category is by far the most widely used and will be 
f ocussed upon in this report . 

Within the range of disk types, a large variety exists, star- 
ting with 3 inch diameter micro floppy disks and ranging to 
hard disks . 

The following table offers an overview of their capacity. 



DRIVE TYPE. 


DIAMETER. 


STORAGE CAPACITY 


Floppy disk 


3 


inch 


100 - 250 


Kbyte. 




5.25 


inch 


125 -1000 


Kbyte. 




8 


inch 


250 -2000 


Kbyte. 


Winchester disk 


5.25 


inch 


2-10 


Mbyte. 




8 


inch 


5-40 


Mbyte. 




14 


inch 


20 - 200 


Mbyte. 


Hard disk over 


14 


inch 


over 200 


Mbyte. 


Table I. 
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The choice of a certain type of disk drive will largely depend 
on its application. Storage capacity will in most cases be the 
decisive factor allthough access-time and cost-effectiveness 
play an important role as well. 

Very recently, a growing trend towards the application of Win- 
chester drives has developed, espescially for small and medium 
sized computer systems. The traditional floppy disk drives, 
commonly found in these applications, are gradually replaced by 
Winchesters . 

The explanation for this development is obvious. Due to finer 
and more accurate mechanical parts and new head materials, Win- 
chester drives have become a very favourable alternative to 
floppy disk drives in terms of storage capacity, access-time, 
reliability and more important, price per bit. It is for these 
reasons that this report will concentrate on Winchester drives. 



1.2. Winchester Disk Drives. 

The classification "Winchester" stands for a drive technology 
that employs a sealed disk and head-positioning assembly. 
This eliminates the need for complicated and thus expensive air 
filtering provisions and air flow control required for hard 
disks . 

The first Winchester type drive was deve Hoped around 1973 by 
IBM, contained a double 30 Mbyte disk and was given type number 
3030 as a result of that. This model number must have been 
associated by several people with the notorious Winchester 
double barrel riffle since this nickname was soon used and has 
been used for this drive technology ever since. 

The major advantage Winchesters offer, as opposed to floppy 
disks, is the fact that the read/write heads fly above the disk 
surface on an air cushion, as is the case with hard disk 
drives. This air cushion is created by the speed of the disk in 
conjunction with the special shaped flexure, the flexure being 
the metal holder upon which the heads are mounted. The absence 
of physical head-medium contact enables faster disk speeds and 
associated data recording speeds. Presently, a recording speed 
of 5 Mbit/sec is quite common for the smallest Winchester 
drives . 

Table II highlights some of the features of Winchester disk 
drives compared to floppy disk drives . 
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DIAMETER HEADS CAPACITY RECORDING TRACK 



( inch ) 




( formatted ) 


DENSITY 


DENSITY 


FLOPPY 5 . 25 


1 


100 


Kb 




48 tpi 




2 


200 


Kb 






8 


1 


500 


Kb 




96 tpi 




2 


1 


Mb 






WINCHESTER 5.25 


2 


5 


Mb 


6-10 


255-980 tpi 




4 


10 


Mb 


6-10 


255-980 tpi 


8 


2 


20 


Mb 


6-10 


255-980 tpi 




4 


50 


Mb 


6-10 


255-980 tpi 



Table II. 



1.3. Disk controller. 

Choosing a Winchester disk drive as a background mass-storage 
device, is not the complete solution to the problem. A link 
between the host computer and the drive will have to be esta- 
blished. This link is usually formed by a disk controller 
device. Either a disk controller is bought or it is developed 
and built by the purchaser of the drive. When buying a con- 
troller, the user has little or no knowledge of its operation 
and has to settle for a standard controller device. When desig- 
ning and building however, all customer specific demands amd 
requirements can be taken into account, leading up to a flexi- 
ble customized controller. 

The object of this graduation project was to design a control- 
ler, capable of controlling a wide range of Winchester drives 
and interfacing with an arbitrary host computer system. 
In the next chapter we will go into the details of this pro- 
blem. 
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Chapter 2. PROBLEM DEFINITION. 



Introduction . 

Prior to formulating the project covered in this report, a 
survey of the functions performed by a traditional controller 
is given. This will give a better insight into the problem at 
hand. Subsequently, the position of the disk operating system 
within a computer environment is discussed. 

Equipped with this knowledge, the project definition is 
formulated in the last paragraph of this chapter. 



2.1. Disk Controller operation. 

Looking at a conventional computer system which uses disks as 
background memory, one can abstract a raw system model as is 
done in figure 2.1. 







Application 
programs 










disk 

operating 
system 


















controller ■ 







Figure 2.1: conventional computer system model. 



8 



The controller constitutes the link between what will 
henceforth be called the Host computer and one or more disk 
drives. For this purpose it entails a number of functional 
modules which will be described briefly in the next section. 



2.1.2. Controller functions . 

A functional block-diagram of a standard type disk controller 
is depicted in figure 2.2. In discussing the different modules 
we will distinguish between three kind of operations: 



Disk write operations . 
Serializer . 

Data from the host is presented in either bytes or words, 
generally in a paucallel format. Recording on the disk surface 
however is done serially, implicating the parallel data has to 
be serialized. The serializer performs this rather straight- 
forward operation by means of a parallel in/serial out shift 
register . 



CRC generator. 

To increase data integrity, a cyclic redundancy checksum is 
calculated and added towards the end of a block of data - 
usually the size of one disk sector. This CRC control function 
enables verification of data upon reading and thus increases 
the reliability of the disk information. 

Using CRC, the serial bits of information are treated as the 
coefficients of a binairy polynomial P(x). This polynomial is 
modified to an extent that makes it exactly divisible by a 
fixed polynomial G(x). The divisor G(x) is refered to as the 
generator polynomial. The modified polynomial, M<x) of all the 
data bytes in a block is added. The result of this addition is 
recorded at the end of the datablock on the disk. 
The reason CRC is used as an error detection scheme, is because 
of its advantages over other methods. Some of these advantages 
are : 



- all errors within n successive bits are detected . ( n 
is the number of bits in P(x). ) 

- for even G(x), all errors with an odd number of bits 
in error are detected ( 50 % of all possible random 
errors ) . 

- All error patterns that are not divisible by G(x) are 
detected as erroneous . 



1. 
2. 
3. 



Disk write operations . 
Disk read operations . 
Drive control operations . 
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Figure 2.2: Controller function block diagram. 
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On top of this, CRC is efficient in that the number of control 
bits is relatively small compared to the number of data-bits. 



MFM-encoder . 



The format in which data from the serializer amd the CRC 
generator is presented, is known as MRZ. (Mo Return to Zero). 
This format is unsuitable to cause flux reversals on the disk 
surface. Furthermore, timing information is stored on disk 
along with the databits to allow proper readback operation. 
To overcome this problem, a MFM-encoder is used, converting MRZ 
data and clock information into MFM data. (FM data represen- 
tation is not discussed here since it is never used for 
Winchester drives. ) 

Figure 2.3 gives a timing diagram of different data represen- 
tation waveforms used for disk storage. 



NRZ 




FM 



1 

1 
1 

MFM 1 

1 
1 








1 
1 
1 
1 
1 
1 








— 1 




1 bitcell 
^ ^ 




data pulseposi t ion 

clock pulse 



Figure 2.3: Data representation waveforms. 



MFM is generated from MRZ according to the following rules. 

1. Every bitcell contains either a data pulse, a clock 
pulse or no pulse at all. 

2. A logic 1 in NRZ is represented by a data pulse in 
the corresponding bitcell. 

3. If the logic bit in MRZ is 0, then no data pulse is 
present in its corresponding bitcell. 
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4. If the previous bitcell contained a data pulse, the 
clock pulse in the next bitcell is missing. 

5. If the previous bitcell contained no data pulse, 
there will be a clock pulse in the next bitcell. 

This scheme may seem confusing at first but it will no doubt 
become clear when reading the next paragraph on data reading. 



Precompensation . 

Due to the fact that the rotational velocity of the disk is 
uniform, there will be am increase in lineair velocity of the 
disk surface passing under the read/write head. This increase 
is proportional to the track number, the most inner track 
having the highest track number. 

As a result of this, the spacing between subsequent flux 
reversals of data and clock bits becomes smaller on the inner 
tracks of the disk, (bit crowding). If the spacing becomes too 
small, adjacent flux reversals tend to influence each other, 
resulting in bit shifts. 

During a read operation, the read/write head develops a current 
as it encounters a flux reversal caused by either a clock or a 
data bit. It takes a finite time for this current to reach its 
peak value. During this time, the disk surface passes on ouid 
the next flux reversal crowds under the head, resulting in its 
peak current being summed with the previous one. In effect, 
this means the bit is shifted from its proper location. Figure 
2.4 illustrates this effect. 




Fortunately, this effect is predictable and can be compensated 
by pre-shifting the bits in the opposite direction. This pre- 
shifting is done by the pre-compensation circuitry. As soon as 
writing is done on inner tracks - tracknumber greater than a 
predetermined value - the recorded bits are shifted back (early 
write), not shifted (on time) or delayed (late write) by a 
small amounth of time. On reading back the recorded infor- 
mation, the bits will appear to be on time. 
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Address Mark generator. 



As a rule, Winchester disks are soft sectored. Thus address 
information concerning track and sector number has to be 
recorded on the disk. This information is present in the form 
of identity fields or in short ID-fiels. The combination of an 
ID-field and a Data field forms a sector. The start of an ID 
field has to be detectable by the controller. For this purpose 
markers are present called Address Marks or AM. Address Maxks 
distinguish themselves from other bytes by means of a missing 
clock pulse, i.e. a violation of the MPM encoding rules. Refer 
to figure 2.5. 



MFM 



DATA 
A1 



CLOCK 
(JA 



missing clock pulse 



Figure 2.5: Address Mark generation. 



The address mark generator takes care of this clock bit 
suppression . 



Line drivers, 



To ensure distort ion- free transmission of MFM data between 
controller and drives, differential line drivers are used. The 
exact electrical specification of these drivers is dependent on 
the drive manufacturer. 
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Disk read operations . 



Pha^e locked loop. 

The initial phase in the read process, consists of abstracting 
the timing information recorded on the disk. The most accurate 
method is to use a phase locked loop, consisting of a pheise 
comparator, a low pass filter and a VCO. The VCO is constantly 
being adjusted by the information derived from the clock pulses 
on the disk. As a result of this, the output of the VCO is in 
synchronization with the data stream from the disk. 



Data separator. 

The data separator, effectively a HFM to NRZ data converter, 
generates separate data and clock pulses from its MPM input 
signal. The output of the forementioned VCO is used for 
synchronizing this data separator. 



Address Mark Detection. 

To find the beginning of an ID-field, the controller has to 
search for an Address maxk. The address meirk detector triggers 
on a missing clock pulse in the KPM data stream. Depending on 
whether the AM belonged to an ID-field or a Data field, sub- 
sequent bytes are read and interpreted by the controller. 



CRC check. 

The next phase in the read process is the CRC check. The CRC 
checksum, calculated by the CRC check circuitry conform para- 
graph 2.1, is compeired with the checksum read from the disk at 
the end of the data field. A mismatch will result in an error 
signal, indicating the received data block contains errors. 



Deserializer . 

As is suggested by the name, the deserializer performs the 
inverse function of the serializer, converting the serial NRZ 
data from the data-separator in 8 or 16 bit words. 
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Drive control operations. 



The third section of the controller exists of a number of 
control and status lines that enable it to control the 
n^chanical parts of the drives connected to it . The most 
connnonly used control and status lines are listed below. 



Step 

Direction 



Head select 



Drive select 



Moves the head assembly one track 
Indicates the direction of the 
movement . Combining the step- 
signal allows positioning of the 
track of the disk. 

Selects a single head of the head 
reading or writing. 

Selects one particular drive in the daisy chain 
connected to the controller. 



head assembly 
and direction 
heads on cuiy 

assembly for 



Ready Indicates the drive is ready for operation. After 

a start-up, it requires some time for the disk to 
reach its operating velocity. During this time 
the drive is not ready. 

Track Indicates the heads are at track zero. This sig- 

nal is required for head calibration after a 
start-up or a reset . 

Seek end Indicates the heads have reached their destina- 

tion and are stable after a head movement opera- 
tion. 

Write fault As a result of an incorrect operation, more than 
one head has been selected for writing or write 
current is flowing through a deselected head. 

Index The index pulse signals the beginning of a track. 



2.1.3. Conclusion. 

The aJsove presents a general overview of the most predomineuit 
characteristics of a disk controller. A more detailed 
discussion of this topic is considered superfluous since the 
controller concept discussed in this report uses advanced 
integrated modules for implementing these controller functions. 
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2.2. Disk operating system. 



So fax, we discussed the hardware provisions needed to connect 
one or more Winchester drives to a host computer. Using this 
hardware set-up, the host tias the capability to control the 
drive and to store and retrieve data on a sector basis . 
The next layer in the hieraxchie of data storage lies between 
this physical disk control layer and the logical data structure 
of the host computer. 

Any user of the host computer system, wanting to manipulate 
data, does so by using a logical data structure. The most com- 
mon structure is a file structure. Every collection of data 
items that meets a certain format is called a file. Piles can 
again be devided into one or more records . 

To be able to read and write files to and from a disk, a trans- 
lation has to be performed between a logical file or record euid 
the physical sectors on the disk where the information contain- 
ed by that file or record will be stored. Consequently, the 
host computer has to have knowledge of the physical organiza- 
tion of the disk. 

Furthermore, the host computer has to supply the user with an 
access mechanism that allows easy reading, writing and manipu- 
lating of files . Thus a set of commands the user can apply has 
to be provided by the host computer. 

Summarizing, one can list the functions of this intermediate 
layer between disk controller smd host computer as such: 

- File structure support . 

- Free disk space allocation and administration. 

- File directory support . 

- File manipulation support. 

Henceforth, the collection of these functions will be referred 
to as Disk Operating System (DOS), since they allow the user to 
operate the disk. 
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Figure 2.6. places the DOS layer in its context. 



user application 
programs 



disk operating 
system 



disk controller 
hardware 



disk drives 



HOST COMPUTER 



DISK CONTROLLER 



DRIVES 



Figure 2.6: DOS layer position. 



2.3. Project definition. 

Traditionally, the Disk operating System forms an integral peurt 
of the host computers' overall operating system, as indicated 
by figure 2.6. 

The object of this graduation project was not only to design a 
universal Winchester disk controller, as mentioned in chapter 
1, but also to add to the controller those functions concerning 
disk storage, normally performed by the host computer operating 
system. Taking this approach implies the design of an intelli- 
gent disk controller, to be used in conjunction with an arbi- 
trary host computer. Figure 2.7. shows the situation that ari- 
ses when applying an intelligent disk controller. 
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application programs 



HOST COMPUTER 



communication layer 



disk operating sy stem 



controller hardware 



DISK CONTROLLER 



disk drives 



Figure 2.7s Intelligent Disk Controller position. 

This constitutes a new approach towards controller design. 
Veirious responsibilities residing in the Host computer, axe now 
being transferred to the controller. This should enable the 
controller to operate in conjunction with a large variety of 
host computers . 

A further design requirement involves maximum universality of 
the controller towards different types of Winchester drives. 
The concept of the intelligent Winchester Disk Controller will 
be presented in the next chapter. 

A summary of the system requirements is given below. 

- Integrated Disk Operating System. 

- High level communication between controller and Host. 

- Support of multiple Winchester Drive types. 
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Chapter 3. WINCHESTER COMTRDLLER CONCEPT. 



3 . Winchester Disk Controller Concept . 



From the requirements mentioned in the previous chapter, two 
subsytems can be deduced that constitute the Winchester Disk 
Controller. The first subsystem is formed by the hardware, 
which is drawn in figure 3.1. The second subsystem is the 
software which operates the controller. 



3.1. Controller hardware . 



The hardware of the controller can be divided into four parts: 



1. Drive control unit. (DCU) 

2. Processor system. (PS) 

3. Host Interface unit. (HIU) 

4. Memory system. (MS) 





host 




processor 




drive 






interface 




sy s tern 




control 






unit 








unit 





memory 
system 



Figure 3.1: Controller block diagram. 
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3.1.1. Drive Control Onit . 



The drive control unit interacts directly with one or more Win- 
chester Disk Drives. Its functions include: 

- Selecting the appropriate drive. 

- Positioning the heads on a specified track. 

- Formatting soft sectored disks. 

- Write sector. 

- Address Maxk Detection. 

- Read sector. 

In short, this is the part which is commonly regarded as the 
actual disk controller. In our concept however, it only forms 
part of the integral controller. 



3.1.2. Processor System. 

The controllers processor system comprises three different 
major tasks: 

1 DOS execution. 

2 Communicating with the disk through the Disk Control 
Onit . 

3 Communicating with the host computer system through 
the Host Interface Unit. 

As the nature of these tasks allows for a division in proces- 
sing (1) and I/O (2,3), the processor system will be separated 
in two sections. One central processing unit will be used for 
executing the Disk Operating System, a separate I/O processor 
will perform all neccessary communication between the Winches- 
ter Disk Controller, Winchester Drives and Host Computer. 



3.1.3. Host Interface Dnit. 

Obviously some sort of connection has to be established between 
the controller and the Host Computer. Wether this connection 
exists of a parallel or a serial link is of no major importance 
at this stage. There are however some requirements this connec- 
tion has to meet : 

- Maximum transfer speed of data to minimize delays 
caused by records or files in transport between Host 
and Controller. Thus, either a parallel link with DMA 
capability or a high speed serial data link will be 
needed . 

- Reliability to prevent the neccessity of 
retransmission or data inconsistency caused by 
transmission errors . 

At this stage it is premature to dwell upon the possible imple- 
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mentations of such a connaunication link as these axe to a large 
extent dependent on the Host Computer used . 



3.1.4. Memory System . 

The Winchester Disk Controller's memory system serves a dual 
purpose. Firstly it incorporates the programs neccessary for 
controller operation. These programs axe either pemanently 
stored in ROM or loaded from reserved tracks of a disk into 
RAH. 

Secondly, a data buffer has to be provided for, to compensate 
for speed differences between disk and host. Furthermore, the 
DOS needs memory for storage of administrative information. The 
more information that can be kept in the controllers workspace 
at a time, the faster file access can be achieved by minimizing 
the number of disk accesses . 



Summeirizing, we come to the following hardware concept block 
diagram. (Figure 3.2.) 

In chapter 4 we will go into the details of every part of the 
block diagram. 
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Figure 3.2: Controller functional block diagram. 
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3.2. Disk Storage Organization . 

In order to map the users logical files to the physical disk 
storage space, an organization has to be set up that performs 
this task with a minimum amounth of overhead. 

The choice of the file structure employed is of extreme impor- 
tance as it has a major impact on the systems performance . 
Rather than starting from scratch, the UNIX file structure was 
tcUcen as a guideline. The reasons for this choice are twofold; 

First of all, the UNIX Operating System can indulge in a fast 
growing popularity, especially for use in small to medium com- 
puter systems. The multi-user / multi-task facilities offered 
by DNIX are remarkably powerful. It is on these devices that 
Winchester Disks are used more and more . 

Secondly, UNIX is quite a transparant operating system compared 
to others. This makes it relatively easy to adopt to specific 
needs. In spite of this, the software behind UNIX is considered 
to be sufficiently uncomplicated to be implemented partially - 
the file handling part to be exact - in the Winchester Disk 
Controller at hand. 



As a result of this choice, the reader may discover various 
aspects in the following section that are very much like UNIX. 
However, it should be noted that alterations were made at cer- 
tain points where they were considered useful for this parti- 
cular application. 



3.2.1. Physical storage . 

Information on the disk is stored in blocks of fixed length 
called sectors. The size of one sector on a Winchester disk is 
usually selectable between 256, 512, 1024 or more bytes/sector. 
This selection is made before formatting the disk. Unix assumes 
a sector length of 512 bytes, a size which is supported by all- 
most all Winchester drive manufacturers. We will adopt this 
sector length as well. 

In figure 3.3 a schemat ic view of a typical Winchester Disk 
Drive ( 2 disks, 4 heads ) is given. Each individual sector is 
addressable by specifying head, cylinder and sectornumber . 

UNIX treats files as contiguous arrays of characters. Thus a 
file is mapped on a ntimber of sectors on the disk, large enough 
to contain the file. Any structuring of data within a file is 
left to the program that operates on the file. Allthough this 
kind of unstructured files enables the use of them in many 
different ways, this loose scheme was considered unsuitable for 
the application at hand . 

The file system we wish to offer the Host computer should have 
structured files. For this purpose, files are made of one or 
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more logical records. The length of these records is determined 
by the file type. The information concerning the structure of a 
file is kept in the file descriptor, (refer to 3.2.2.) 

The most straightforward method to store structured files is to 
map each logical record to one or more sectors of the disk. As 
a rule, the last sector thus used will not be fully occupied 
with data. They will be filled with empty chaxacters. Figure 
3.4 shows a comparison between the UNIX strategy and the 
alternative solution. 
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Figure 3.4: File storage. 



From this comparison it is obvious that the UNIX file scheme 
uses the available disk space much more efficiently. Only when 
record lengths are a true multiple of one sectorlength they can 
be neatly mapped and can the other scheme be used effectively. 
This implicates a recordlength of 512 bytes for most Winchester 
drives. Since this is rarely the case, the ONIX scheme for 
storage will be adopted. However, the controller's DOS will be 
equipped with routines that offer structured files to the Host 
computer . 

Implementation of these files is achieved by using the infor- 
mation on the record length of a file present in its file des- 
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criptor. After reading the required number of blocks in the 
controllers workspace, the structure of the file is assembled 
using the file desciptors information. Figure 3.5. illustrates 
this process. Obviously, this storage method is a trade-off 
between fast random access to file records and efficient disk 
space usage. 
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Figure 3.5: File structuring. 
3.2.2. File descriptor. 

Every file is described by a file descriptor containing all the 
relevant information on that particular file. In ONIX, file 
descriptors are referred to as index-nodes or l-nodes. An 
Index-node contains the following information: 
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1. Identification of the user and owner of the file. 

2. Access rights. 

3 . Address information concerning the physical location 
of the file on disk. 

4. File size, i.e. the number of physical blocks it 
occupies . 

5. Number of links to the file, i.e. number of times it 
appears in the directory. 

6. File type: User file, record length ; Directory 
file. 

The I-node describes the entire file and provides the informa- 
tion required to access its contents. 

Notice that some modifications were made to the standard UNIX 
I-node . 



3.2.3. Address information . 

The address information on a file is organised as 13 4 byte 
pointers. The first 10 pointers correspond directly to the 
first ten blocks (disk-sectors) of the file. The llth pointer 
points to a block containing 128 pointers to the next 128 
blocks of the file. If the file is longer than 138 blocks, 
pointer 12 of the I-node is used as a double indirect pointer. 
It points to a block of 128 further pointers, each pointing in 
their turn to pointerblocks , containing pointers to the subse- 
(luent blocks of the file. Finally, pointer 13 is used as a 
tripple indirect pointer. As a result of this, each file can 
occupy a maximum o£ 2,113,S74 512 byte blocks on the disk. 
This upper limit is considered sufficient to accomodate most 
file lengths. Note that large files become increasingly unprac- 
tical to operate upon. 

This organization allows relatively short files (less than 5120 
bytes) to be addressed directly through the I-node. Longer 
files require an extra indirection i.e. an extra disk access 
and thus a longer access time, as might have been expected. 
The end of a file can be signaled by a null pointer, following 
the pointer to the last block of the file. 

Two different pointer types will be used: 

-Indirect pointer ( I ) : pointing to a pointer block . 
-Sequential pointer (S): pointing to a file block. 

The reason for this distinction will become clear in chapter 5 
when discussing record insertions. Obviously pointer 1 through 
10 in the I-node are S-type pointers whereas 11,12 and 13 aure 
I-type . 

Refer to figure 3.5. for a graphical representation of the 
pointer mechanism described. 
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Figure 3.6s Pointer mechanism . 




3,2.4. Index list . 

All index nodes, and thus all files, can be found by searching 
through the Index-list ( I-list ) . The Index-list is a list of 
all I-nodes in the system ajid starts at a fixed location on the 
disk. The length of this list, determined by the number of I- 
nodes, may be such that it covers more than one block of the 
disk. Therefore the I-list will be dispersed over a number of 
blocks . We will discuss to possible solutions to organize this 
Index- list . 

a) Linked list: Using a linked list method, every block of the 
I-list is terminated by a sequential pointer to the next 
block of the list . The major advantage of this method is the 
possibility to expand the I-list when required. However, 
searching through the list for a particular I-node can only 
be done linearly by starting from the first block, which is 
at a known position. This can be a very time consuming pro- 
cess, especially when the I-list becomes dispersed over the 
disk due to multiple extensions. To overcome this problem, 
it would be favourable to keep the I-list in the control- 
lers' workspace as much as possible. This would eliminate 
the need for multiple disk accesses but would on the other 
hand claim considerable amounths of controller workspace . 

b) Fixed list : Using a fixed list means the I-list is stored 
on a fixed number of contiguous blocks on the disk. This 
means a predetermined number of blocks will have to be 
reserved for the I-list. Expansion of the I-list becomes 
impossible. Once it is filled, no new I-nodes can be added, 
unless another I-node is deleted first. Thus there is a 
maximum number of files that can be resident in the system. 
Though this method may seem unfavourable, its strength lies 
in the ability of the controller to access an I-node direct- 
ly by calculating its position on the disk. Thus the I-list 
need not be kept in workspace since one integer number is 
sufficient to locate the proper I-node. 



In Figure 3.7. both methods are shown. 

Allthough a linked I-list offers more flexibility, a fixed list 
will be used to allow easy access to an I-node and thus a file. 
The consequence of this choice is the limitation to a predeter- 
mined number of files . 



3.3. Directory structure. 

Access to a file is obtained through the Index-node. Rather 
than searching through the index-list lineairly, looking for a 
particular Index-node, a hierarchy of directories is added to 
the controller concept . 

In UNIX, a directory is considered a^ an ordinairy file with 
limited access rights, only the system can create, write and 
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Figure 3.7: Index list. 



modify a directory file. A directory file is majrlted as such in 
the corresponding Index-node. 

An entry in a directory file comprises two fields . The first is 
occupied by a symbolic alpha-numeric name of limited length . 
The UNIX convention is 14 characters maximum and as this is 
considered a reasonable amounth, it will be used in this con- 
cept as well. 

The second field contains a two byte integer number, called the 
Index-number or I-number. The Index-nuinber is an offset in the 
Index- list, leading directly to the Index- node of the file that 
corresponds to the symbolic file name . 

Refer to figure 3.8. for a graphic representation of the direc- 
tory mechanism. 

Due to the fact that files refered to in a directory can be 
either user-files or user defined sub-directories, a tree-like 
directory structure is created. The user can thus specify a 
file by its path through this tree structure. The controller 
converts this pathname into the desired Index-node by starting 
to look in the current directory of the user at hand . The first 
component of the pathneune is searched in this directory and 
when found, results in an Index-node. If it was the last compo- 
nent of the pathname, the Index-node found is the final result. 
If not, the next pathname component is searched in the file 
corresponding to the Index-node just found. Mote that in this 
case the file type had to be directory . Figure 3.9. illustrates 
this tree-directory structure . 

Apeurt from its straightforwardness and simplicity of implemen- 
tation, this directory mechanism offers advantages in respect 
of access-right validation and file protection. 



Two standard entries in every directory are worth mentioning 
distinctively. UNIX uses a single and a double dot as symbolic 
name to refer to these entries. The first refers to the direc- 
tory itself enabling the user to read his current directory 
without knowing its name. The second refers to the parent of 
the directory in which it appears, this parent being the direc- 
tory in which it was created. This entry allows for backtrac- 
king through the directory tree. 
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3.4. Free space administration. 

In order to prevent the controller from writing different files 
on the same physical location of the disk, it has to Xeep track 
of the available space on the disk. Furthermore, it is this 
part of the DOS that is responsible for allocating disk-space 
to a new file and re-allocation of space that becomes availaJsle 
on the deletion of a file. 

Looking at the UNIX operating system again, one encounters a 
strategy of blocks containing 50 pointers to free blocks. These 
pointer blocks form a linked list. 

The alternative to this scheme, found in many Disk Operating 
Systems is the use of a bit-map, A bit-map is an aucray of bits, 
each corresponding to one sector or block on the disk. The 
value of a bit indicates whether the corresponding block is 
free or not. 

The following two paragraphs deal with the advantages and dis- 
advantages of both methods. As a result of this comparison, a 
choice for either method will have to be made. 



3.4.1. Free block pointer list . 

Two disadvantages of the UNIX free block pointer list stand 
out: 

1. On starting with an empty disk, pointers to all free blocks 
on the disk have to be initialized. This leads to a tremen- 
duously long free block pointer list. Alternatively, one 
could start of with a limited list and add more blocks to 
the list as disk usage increases . 

2. Whenever space has to be re-allocated, for instance after 
deletion of a file, the pointers to the freed blocks have to 
be added to the list. 

The process of re-allocation can best be illustrated by an 
example . 

Assume the controller has a pointer block to the free blocks on 
the disk in its workspace. This paxticular block can be consi- 
dered as the current free block pointer. Part of the blocks 
pointed to has allready been allocated to different files and 
therefore marked null. The other part is still available as 
free space. Refer to figure 3.10. 

Two situations can occur at this point: 

1. A new file is created and space has to be allocated for this 
file. The number of blocks to be allocated depends on the 
file type. Say ten blocks have to be assigned to this file 
initially. The controller starts looking in its current free 
block pointer block until it encounters a non-zero pointer 
which is subsequently assigned to the new file. After the 
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Figure 3 . 10 : Current free block pointer . 



assignment, the pointer in the free block pointer block is 
set to zero. After assigning the last pointer in the free 
pointer block, the controller will encounter the indirect 
pointer which points to the next block in the free block 
list. This block is then loaded in the controllers workspace 
and becomes the new free block pointer block. 
This algorithm is straightforward and causes no serious pro- 
blems . 



2. A file is deleted and the blocks previuosly occupied by this 
file have to be registered as free blocks. If the number of 
blocks involved is less than the number of empty entries in 
the current free block pointer block, no problem occurs . The 
pointers to the blocks returned by the deleted file are re- 
corded in the current free block pointer block. 
If however the niimber of blocks to be freed exceeds the num- 
ber of unoccupied entries - and this will usually be the 
case - then a new element in the free block pointer list 
will have to be created. The problem with this new element 
is, where to locate it on the disk. 

From this example we learn that the major problem using a free 

block pointer list lies in the expansion of this list. We offer 

three alternatives to overcome this problem: 

First of all, one could use one of the blocks turned free by 
the deleted file as the next block in the free block pointer 
list. Conveniently this would be the block following the last 
block that could be placed in the current pointer block. 
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This would however lead to a dispersed free block pointer list 
since the block thus added could be located anywhere on the 
disk. It is considered good policy to try and confine this list 
to a restricted area of the disk. This way long access times 
for allocating free space to a new file can be avoided . 

Secondly, one could use a double pointer list, meaning every 
block in the list contains a pointer to its predecessor and a 
pointer to its successor. Thus a rather fixed structure of 
pointer blocks is created which can be restricted to a prede- 
termined area of the disk. 

Thirdly, a fixed number of contiguous blocks could be reserved 
on a restricted area of the disk, similar to the Index-list 
described in a previous paragraph. This method however coioes 
very close to that of a bit-map, every bit being replaced by a 
4 byte pointer. 



Summarizing one can say the first method leads to a dispersed 
free block pointer list which is quite undesirable. The second 
method requires a seperate adminstration of blocks that can be 
attached to the free block pointer list. This seperate admini- 
stration can be conceptually simple, e.g. a bit-map, but the 
extra overhead involved for expanding the list, is considered a 
major disadvantage. The third solution finally, involves mas- 
sive waist of disk space since a 4 byte pointer is reserved for 
every physical block on the disk. 

In figure 3.11. the three different ways to organize the free 
block pointer list are drawn. 
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Figure 3.11: Free Block List. 



3.4.2. Bit-map . 

The use of a bit map for free space administration is quite 
common, due to its conceptual simplicity. Since every block on 
the disk requires only one bit of administration, the overhead 
is minimal. The most predominant disadvantage of a bit map so- 
lution, lies in the required calculation from bit position 
within the bit-map to actual block address. Furthermore it is 
difficult to define a fast algorithm for efficient allocation 
and re-allocation of free space. 
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From the previous discussion, it is obvious that the bitmap 
method will be used in this controller, as opposed to the free 
block pointer list . The processing power of the controller is 
sufficient enough to overcome the problem of translating bit 
position within the map to physical disk address . 



Concluding this section of chapter 3, I would like to state 
that some features of the ONIX file system are not present in 
the concept described here. Partially this is due to the fact 
that modifications were considered neccessary to meet the re- 
quirements of a controller capable for operating in a non-UNIX 
environment, partially it resulted from pragmatic choices made 
to enable an easier implementation of the file system on the 
controllers CPU. 
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3.5. Command Structure . 

The most essential part of a Disk Operating System, from the 
user point of view, is the command set it offers. The scope of 
these commands determines the degree of intelligence of the 
controller as it manifests itself to the user. 
In order to reach a functional set of commands to be implemen- 
ted by the DOS, a few requirements the controller has to meet, 
have to be kept in mind: 

- Function as background storage for user and system 
files . 

- Easy and fast reading and writing of files. 

- Both sequential and remdom access . 

- Support of a logical file structure for the purpose 
of reuidom access . 

- The set of commemds offered must be as small as pos- 
sible for ease of use yet sophisticated enough to 
perform any manipulation the user whishes to do with 
his files. 

Some of these requirements are contradictory to a certain 
extent so compromising need be done. 

In order to obtain a general purpose set of commands, a survey 
was made on existing operating systems and the set of commands 
they offer. This survey resulted in a command set, described in 
the following section of this chapter, which is considered to 
be a reasonable compromise between complexity of implementation 
and file manipulation capability. Two different classes of 
functions are distinguished, file handling commands - covered 
in paragraph 3.5.1. - and directory commands - covered in 
peLragraph 3.5.2. 



3.5.1. Pile handling commands . 

Below, a list of available file handling commands is given. 
Every command will be elaborated upon by giving a functional 
description, the result of the operation following the command 
and a list of possible error conditions . 

Create 

Open 

Close 

Delete 

Read 

Write 

Recover 

Seek 

Insert 

Erase 
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Create . 



Function : Creation of a new file by assenibling its In- 

dex-node. Information regarding the users 
identity must be supplied for protection in- 
formation and access-right validation. 



Result : The create command results in the creation 

of an Index-node containing all known infor- 
mation on the file created. The Index-node 
is added to the Index-list for future re- 
ference. Furthermore, an entry in the users 
current directory is made. If necessary, 
space for either the new Index-node or the 
directory entry must be allocated. 



Error conditions : 1. Illegal filename. The filename and file- 
type combination supplied by the user, all- 
ready exist in his directory. 
2 . No space . The physical space required to 
create the new Index-node and directory en- 
try is not available . 



Open . 

Function : The open command activates the file speci- 

fied by the user. 

Result : Activation of a file means the Index-node of 

the file is fetched from the Index- list and 
added to the active Index-node table in the 
controllers workspace. Access to this active 
Index-node table is obtained through the 
users open file table. The open file table 
consists of the users file names which are 
currently open and an offset into the active 
Index-node table . 

This substructure allows for fast access to 
the file for future reference . 
Figure 3.12. illustrates this scheme . 

Error conditions : 1. File allready open. Filename and type is 

encountered in the users open file table, 
indicating it was opened previously. This is 
not an error in the true sense since the 
file will be open after issueing the com- 
mand . 

2. Illegal access. User has no legal access 
rights to the file he specified. 

3. No file. Filename specified by the user 
is not present in his directory or any of 
the directories he has access to. 
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Figure 3.12: File access substructure. 



close . 



! closing a file, i.e. remove the access me- 
chcuiism to the file. 

: As a result of the close command, the entry 
in the users open file table is marked 
"deleted" . Thus the information stored in 
the Index-node is maintained. However, 
opening of another file by the same user can 
result in the entry in his open file table 
being overwritten. 

Error conditions : 1. File not open. Files which were not open- 
ed can't be closed. Again, this is not an 
error in the true sense since the file will 
be closed after the command is given. 

2. Illegal access. User tries to close a 
file he has no access rights to. 

3 . No file . File specified is not present in 
the users directory. Note the difference be- 
tween this error condition and number 1. 
"File not open" means the file exists but 
was not open. 'No file' means the file does 
not exist within the users' scope. 



Function 
Result 



Delete. 

Function : Deletion of a file, specified by the user, 

from his directory. 

Result : Deletion of a file is actuated by marking 

its Index-node as "deleted". Thus the Index- 
node is maintained in the hierarchy but is 
not available. The space occupied by a 
deleted Index-node can be overwritten as the 
result of a subsequent creation of a new 
file. 

Error conditions : 1. Illegal access. User has no access rights 

that allow deletion of a file. Files can 
only be deleted by their owner. 
2. No file. File specified cannot be found 
in the users directory. In essence this is 
not a real error condition since the result 
of issueing the command will be the absence 
of the specified file. 

Read . 

Function : Read a logical record from the specified 

file. The record is obtained from the con- 
trollers workspace and transferred to the 
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Host. If the requested record is not present 
there, part of the file is read from the 
disk and stored in the controllers work- 
space. The requested record can subsequently 
be extracted using the record size informa- 
tion contained in the Index-node . 

Result : The result of a read operation is the trans- 

fer of a file record in sequential order 
from the file speciefied. Since files are 
stored on disk as contiguous blocks of data, 
the division of a file into logical records 
has to be done by the controller. Thus, 
files are allways transferred through the 
controller buffer. 

Error conditions : 1. Illegal access. User does not have the 

proper access rights to read the specified 
file. 

2 . No file . Filename specified cannot be 
found in the users directory. 

3. Pile not open. Pile wasn't opened prior 
to read command . 

4. End of file. Either the file being read 
is empty or the last record of the file has 
been read on a previous occasion. 



Write. 

Function : Write a logical record on disk. The record 

is added towards the end of the specified 
file. 

Result ! The record to be written is transfered to 

the controller buffer. Physical writing to 
the disk is not neccessairilly done xmme— 
diately . 

Writing from buffer to disk is done whenever 
a fixed number of blocks - minimum one - can 
be written at once and bufferspace has to be 
made available to service another request. 
As a matter of course, all active records of 
a file, present in the controllers buffer 
but not written to disk yet, are transfered 
to disk prior to a close or read command 
execution on the same file. 

Error conditions : i. Illegal access. User has no write access 

to the specified file. 

2. No file. Filename specified is not pre- 
sent in the users' directory. 

3. File not open. File not open i.e. no en- 
try in users' open file table. 
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4. Not End of File. Present access location 
within the specified file is not positioned 
at the end of the file. Since records are 
added towards the end of the file, a seek to 
file end has to preceed the write command. 

5. No space. Space required to store the re- 
cord is not available on disk or in the con- 
troller buffer. 



Recover . 

Function : Recovering a previously deleted file. The 

inforxaation contained in the recovered file 
can either be intact or distorted. Informa- 
tion concerning the integrity of the reco- 
vered file is supplied to the user after 
execution of this command. 

Result : The result of this somewhat unusual command, 

is based on retrieving the Index-node of the 
file to be recovered, from the Index- list. 
As described previously, deleting a file re- 
sults in its Index-node being marked "dele- 
ted" . This means it is still present in the 
Index- list where it can be found by the con- 
troller, unless the creation of a new file 
caused the entry to be overwritten by the 
new Index-node. In this case, recovery of 
the deleted file is impossible. 
The Index-number of the deleted file has to 
be obtained from the recover file which was 
specially created for this purpose, since 
the normal entry in the directory has been 
removed . 

There is yet another complication concerning 
the disk space previously occupied by the 
deleted file. Upon deletion of the file, the 
blocks it occupied were marked as being free 
. When the file is recovered, a comparison 
between the address information in the In- 
dex-node and the free space adminstration 
table has to be made. If the blocks of the 
recovered file are still registered as free 
blocks, they may still contain the proper 
information, though this is not neccessarily 
the case. This however is an uncertainty one 
has to accept. Therefore the user, after 
issueing a recover command, should also ve- 
rify the information contained in the reco- 
vered file. 

From the above one can conclude that this is 
a very complicated command with uncertain 
results. When implementing a command like 
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this, one has to consider whether the advan- 
tages compensate for the problems it incures 

Error conditions ; 1. No file. File name specified is not pre- 
sent in the recover file, meaning it was not 
deleted . 

2. Mo I-node. Index-node of the specified 
file has been overwritten. 

3. No data. One or more blocks previously 
occupied by the file have been re-allocated 
to other files. 



: The seek command moves the window, a pointer 
to a record within a file, to a specified 
position. Thus random access within a file 
is possible . 

: The window of a file points to a record 
within the file. The value of this pointer 
is stored in the users open file table. Nor- 
mally the window is incremented after every 
read or write operation. Thus sequential ac- 
cess is achieved. By means of the seek com- 
mand, the window can be moved to an arbi- 
trairy position within the file. 

Error conditions : 1. Illegal acces. User has no read access 

rights to the file he specified. 

2. No file. Specified file cannot be found 
in users open file table. Either it was not 
opened previously or it doesn't exist at 
all. 

3 . No record . Specified record nvutiber is out 
of range. The window is set to EOF as a re- 
sult of this. 



Seek. 
Function 

Result 



Insert . 

Function : Insertion of a record in a file at the loca- 

tion pointed to by the window. 

Result : As the result of an Insert operation, a re- 

cord is added to a file at the current posi- 
tion of the window. Records following the 
inserted record are shifted one position as 
is illustrated in figure 3.13. 
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Figure 3 . 13 ; Record insertion . 

After insertion of a record, the controller 
will perform a readback operation to verify 
correct operation. Afterwards, the window is 
moved to the next record of the file . This 
enables multiple insertions to be performed 
sequentially. 

Error conditions ; 1. Illegal access. Oser has no write access 

rights to specified file . 

2 . No file . Specified filename does not 
occur in users directory. 

3 . Not open . Pile exists but is not open . 

4. No space. Physical disk space required to 
store the inserted record is not available . 



ErcLse . 

Function : Erasure of a particular record from a speci- 

fied file, the erased record being the re- 
cord currently pointed to by the window. 

Result : The erase command is the functional counter- 

part of the insert command. Therefore, the 
result is opposite to that of an insertion. 
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Only, an erasure does not affect the posi- 
tion of the window within the file. Thus, 
after an erasure, the window will be at the 
next record position. This allows for mul- 
tiple record erasures. 

Error conditions : 1. Illegal access. User has no write access 

rights to the specified file . 

2. Mo file. Pile does not occur in users di- 
rectory . 

3 . Mot open . Pile specified was not opened . 

4. End of file. Window has reached end of 
file. No more erasures can be done unless a 
seek is executed to a previous record posi- 
tion. The same error condition occurs when 
the file is empty. 
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3.5.2. Directory commajids . 

The second set of coiamands involves manipulation of the direc- 
tory mechanism in the controller. There are two possible ways 
to allow the controller access to the directory. Both possibi- 
lities will be discussed briefly. 

The first results from the fact that directories are just a 
special kind of ordinairy files. Thus, it is possible to per- 
form the same operations on directories as on files . The user 
can define his own directory command set by manipulating direc- 
tory files the same way he would manipulate ordinairy files . 
This however requires a detailed knowledge of the controllers 
directory mechanism. This is contradictory to the purpose of 
the controller concept . All knowledge concerning file organiza- 
tion should be concentrated in the controller, not in the Host 
or at the user. 

The alternative is to provide a number of directory commands at 
the same level as the file commands. The scope of these direc- 
tory commands will have to be limited to recjuiring information 
on a file. Alterations in the controllers directory by the user 
can not be permitted since they would require in depth know- 
ledge of its operation, which is assumed absent at the user 
level . 

Three different directory commands will be supported: 

- DIRLIST : Lists the contents of a directory specified 

by the user. The specification is done by 
supplying a pathname aa described in para- 
graph 3.3. 

- ENQUIRY i Supplies the user with an overview of the 

information contained in a file's I-node. 

- RENAME : Allows the user to alter a file's name. 



3.6. Host Interface . 

To ensure proper communication between the Disk Controller and 
the Host computer, one has to provide for an interface between 
the two. In general, two approaches exist: 

1 . Network solution . 

2. Register solution. 

3 . Bus solution . 
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3.6.1. Network solution . 



Taking a network view towards the communication, the controller 
is regarded as one of the devices connected to the Host compu- 
ter by a link . See figure 3 . 14 . 



host 

computer 
^ 

y 



Figure 3 . 14 : Network model . 

Every device in the network has its own address and monitors 
the communication channel to see whether there is a message for 
him distributed on the network. If so, the message is read and 
interpreted . 
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Figure 3 . 15 : Message format . 
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In a network environment, messages between members are packed 
in blocks of variable length according to a certain format. A 
possible message format might be what is shown in figure 3 . 15 . 

The advantage of this solution is twofold. First of all, it's 
very flexible in that the message blocks can contain any infor- 
mation desired. The protocol only provides for sending and re- 
ceiving messages, regardless of their contents. Secondly, the 
physical transport can be done serially or parallel without amy 
implications for the protocol. In both cases, the transfer 
would be asynchronuous , inflicting no time constraints on 
either host or controller. 

As with any solution, there eu:e some disadvantages as well, one 
of them being the relatively large amounth of overhead invol- 
ved. This overhead has a negative impact on the link's perfor- 
majice . 



3.6.2. Register solution. 

A far simpler solution compeured to the previous one, is the use 
of a set of parallel I/O ports, one for data transfer and one 
for command/status transfer. Thus, the Host sees the controller 
as a peripheral located somewhere in his memory map. 
Though this approach is conceptually simple, it offers little 
flexibility . 

To obtain a maximum performance level, the data-channel at 
least should allow for DMA transfers. 
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Figure 3.16: Peripheral connection. 
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3.6.3. Bus solution. 



The third possibility is to connect the controller directly to 
the Host computer's bus system. This enables the controller to 
directly access the Host computer's memory. Memory to memory 
transfers from the controller's buffer to the Host's workspace 
and vice versa. 

Clearly this means that the controller has to be designed for a 
specific Host computer system or at least a specific bus sys- 
tem, e.g. Motorola's VME or Intel's Multibus bus. 
The design covered by this report does nott however imply in 
depth knowledge of a certain bus system. Therefore this possi- 
bility is dropped. 
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Figure 3.17! Bus solution. 



3.6.4. Conclus ion . 



Due to its conceptual simplicity and reasonable compatibility 
to various computer systems, the register solution was chosen 
in this particular design. 
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Chapter 4. CONTROLLER HARDWARE DESIGN. 



4.1. Int roduct ion . 

The hardware required for a controller described in this report 
is more complex than that of a conventional disk controller 
which functions as a mere peripheral. The blockdiagram shown in 
Figure 4.1. gives a general idea of the scope of the hardware 
for an intelligent Winchester Disk controller. 

Description of this hardware system will be done in five sec- 
tions: 

- Processor system. 

- Memory system. 

- Host interface. 

- Controller module. 

- Disk drive interface. 



4.2. Processor system. 

The processor system constitutes the central part of the hard- 
ware and serves a dual purpose. 

The most predominant task to be executed by the processor sys- 
tem is the transport of data between Host and Disk Drives. This 
requires massive I/O, preferably using Direct Memory Access 
(DMA). Furthermore, the processor system should be able to meet 
the speed requirements of both Host and Disk Drives in order to 
avoid unnecessaxy delays . 

The second task imposed upon the processor system is the execu- 
tion of the controller's Disk Operating System (DOS). To this 
extent, it requires flexible addressing techniques, memory 
management capabilities, a strong set of instructions and feust 
execution speeds. 

These two obviously distinct functions, each imposing special 
demands on the processor's capabilities, lead to the choice of 
a multi-processor system in which every task has a dedicated 
processor . 



4.2.1. Parallel- versus Co-processing. 

The use of more than one processor calls for some sort of com- 
munication and colaboration between the different processors 
involved. Two different approaches can be used, either parallel 
processing or co-processing. 

- Parallel processing. 

Parallel processing means two or more processors, either of the 
same or of a different type, are simultaneously executing peurt 
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Figure 4.I1 Controller block diagram. 
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of a task. Thus the work- load is shared amongst several proces- 
sors, increasing the overall throughput. Peripherals, memory, 
bus etc are shared resources, meaning they can be used by any 
of the processors in the system, only not at the Seune time , 
Communication between different processors is performed through 
Shared memory. 

The use of shared resources requires strict synchronization of 
concurrently running processes, as well as arbitration of 
simultaneous resource requests. Use of the shared bus is usual- 
ly handled by a so called bus arbiter which allocates the bus 
to a requesting processor as soon as it becomes available. All 
bus requests are coordinated by this bus abiter. The processor 
which gains control of the bus is usually also given access to 
the other shared resources such as memory and peripherals. 

As a rule, parallel processing is advantageous in the execution 
of tasks that require considerable processing. The extra in- 
vestments in arbitration hardware will have to be weighed 
against the increase in perf onaaiice . 
Refer to figure 4.2. 
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Figure 4.2: Parallel processing. 



- Co-processing. 

In a co-processing situation, two or more processors are each 
assigned a specific part of a task. However, execution of these 
sub-tasks is done sequentially rather than simultanuously, thus 
only one processor is active at a time and has complete control 
of all the resources. Obviously, the processors involved are of 
a different nature and especially fit for their specific sub- 
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tasks . 

Transfer of control from one processor to another is usually 
done after completion of a sub-task, unless another processor 
requires immediate service. To achieve this, some sort of com- 
munication between the different processors in the system must 
exist . 

A situation found in most co-processor systems is that of a 
master-slave hierarchy in which one master and one or more 
slave processors exist . Whenever the master wants a slave pro- 
cessor to execute a task, it activates the desired slave pro- 
cessor. Once activated, the slave processor takes control of 
the bus, executes its task and signals the master upon comple- 
tion. Exchange of information between processors is done 
through parameter blocks in memory. 

The suivantage of co-processing lies in its conceptual simpli- 
city compared to parallel processing. The price for this 
simpler approach is a lower performance level. 
Refer to figure 4.3. 
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Figure 4.3: Co-processing, 



For the design at hand, a co-processing configuration of a 8086 
16 bit Central Processing Unit (CPU) and a 8089 I/O processor 
( lOP ) was chosen based on the following arguments . 

Transferring large quantities of data to or from the Disk under 
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DMA requires constant use of the system bus. During these 
trsinsports, which are assumed to consume a large percentage of 
the overall time, no other processor can use the shared bus, 
thus no other processor can operate outside of its local envi- 
ronment . Local operation of the lOP would be no solution since 
the Disk operating System, running on the CPU has to operate on 
the data obtained from Disk. Therefor this data has to be 
stored in shared memory which is only accessable throught the 
shared bus. 

This heavy I/O load on the shared bus makes parallel processing 
impractical, especially when the extra hardware needed for a 
parallel processing system is taken into account . 



4.2.2. I/O processor description. 

The Intel 8089 I/O processor is a single chip, high performance 
, general purpose I/O system, equipped with two independent I/O 
channels, each combining CPU capabilities with a flexible DMA 
controller. Each channel can execute a Task block program, 
using 53 instructions specially designed for efficient I/O 
program execution. On top of that, every channel can perform 
DMA transfers with simultaneous data manipulation. 
The architecture of this lOP and its capacity to operate in 
conjunction with a 8086 CPU in a co-processing environment, 
make it very suitable for this application. 



4.2.3. Central Processing Unit description. 

The 16 bit 8086 CPU, family member of the lOP, was chosen for 
this application, rather than the 8088, a similar CPU with a 8 
bit data bus. Allthough most disk systems in the Winchester 
field currently still operate on 8 bit data units, the possi- 
bility of future extension to 16 bits was taken into account. 
Besides, the 8086 is perfectly capable of handling bytes and - 
can obtain a higher performance level them all existing 8 bit 
micros, including the 8088. 

Finally, the ease of applying the 8086 and 8089 in a co-proces- 
sing environment, lead to this choice. 

In figure 4.4. the processor system is shown schematically. 
Circuit diagrams are all concentrated in appendix A of this re- 
port and references to this appendix will be made frequently. 
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Figure 4.4: Processor System. 



4.3. Memory system . 

The memory system required for the controller can be divided in 
two parts. Random Access Memory (RAM) which constitutes the 
controllers workspace and Read Only Memory (BOM) which stores 
the required software permanently, as well as the neccesary Re- 
set and interrupt vectors. 

In order to construct a read/write memory system, either static 
or dynamic RAM chips can be used. The use of static memory ele- 
ments results in a conceptually simple, fast and reliable memo- 
ry system. However, due to the fairly large power consumption 
and lower packing density of static RAM chips, dynamic memory 
elements are usually applied for larger memory systems. Power 
consumption is approximately 10 times, packing density 4 times 
better compared to static memory. 
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The major disadvantage of dynamic memory is the fact that it 
has to be refreshed regularly to avoid loss of information. 
During these refresh periods, the memory is not available for 
the CPU. Furthermore, the timing requirements for the refresh 
actions are rather strict and somewhat complicated. Thus the 
use of a specially designed Dynamic RAM Controller is neces- 
sary. The purpose of this controller is to take the burden of 
refreshing the dynamic chips at reguleu: intervals away from the 
CPU. As a result, the memory system becomes transparant for the 
CPU and acts as static RAM but only to a certain degree. If the 
CPU wants to access the memory during a refresh cycle, it is 
delayed by means of the insertion of WAIT states until termina- 
tion of the refresh cycle. Thus, dynamic RAM may affect the 
processor system's performance. 

Several possible configurations for the RAM system were exa- 
mined. Two of the most interesting possibilities axe discussed 
below to give an impression of what options exist . Memory sizes 
of 64 Kwords and 32 Kwords were assumed respectively in case of 
a Dynamic and a Static system. Memory systems larger than 32 
Kwords are genarally not made using static RAM. 



4.3.1. Dynamic RAM system . 

Designing a dynamic RAM system requires the choice of a DRAM 
chip on the one hand and a compatible DRAM controller on the 
other. Since the processor system is made of Intel devices, an 
Intel DRAM controller seems an obvious choice. The 8207 Advam- 
ced Dynamic RAM controller was taken in conjunction with 2164 
DRAM chips. 



2164 DRAM. 

The 2164 DRAM is a 64K x 1 bit dynamic RAM chip, built around 
four matrices of 128 rows by 128 columns. Row and Column ad- 
dresses, each 8 bit wide, are multiplexed through an 8 bit wide 
address bus. For use in a 16 bit wide datapath system, 16 chips 
is a minimum requirement, yielding a 64 Kword memory system. 

8207 Advanced Dynamic RAM Controller. 

As is suggested by the name, the 8207 is a very complex con- 
troller module. Refer to figure 4.5. for a functional block 
diagram of this controller. 

The ADRC is a peripheral chip which takes care of the addres- 
sing, refreshing and required drive capability for 16K, 64K and 
256K dynamic RAM chips. It provides a dual port function al- 
lowing two independent processor systems to access the same 
memory. A built-in arbiter determines the order in which re- 
quests are serviced. Furthermore, provisions were made to con- 
nect a 8206 Error Detection and Correction Unit (EDCU), yiel- 
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Figure 4.5 Intel 8207 Dynamic Ram Controller 



ding a very reliaitle memory system. It is beyond the scope of 
this report to list all the possibilities of this DRAM control- 
ler . 



The use of this DRAM controller in a RAM systems, leads to a 
very compact design. See figure 4.6. However, the insertion of 
WAIT states as mentioned before, cannot be avoided using this 
controller. The negative impact on the lOP' s DMA performance is 
considered a major disadvantage. 
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Figure 4.6: Dynamic RAM system. 



4.3.2. Static RAM system . 

All the problems regarding timing requirements introduced by 
dynamic RAM chips can obviously be avoided using static memoiry. 
The Intel 2167 High Speed 16K x 1 bit static RAM is the highest 
package density static RAM chip currently available. Due to its 
built in power-down mode, power consumption is kept within 
reasonable limits in spite of the fast access times . ( 100 nsec 
slow version) A 32 Kword RAM system, made from 32 chips, would 
require about 8 Watts under normal operating conditions as 
opposed to 2 Watts for a similar dynamic system. 
The advantages of a static RAM memory, simple timing, fast 
access times, high reliability and easy expandability, lead to 
the choice of a static RAM memory for this particulau: design. 
If however the assumed memory size of 32 Kwords should prove to 
be insufficient, the choice of DRAM is obvious. 
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See figure 4.7 and appendix A. 
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Figure 4.7: Static RAM system. 



4.3.3. RDM system . 



The ROM system shown in appendix A can be hard-wired to accomo- 
date either 2732 4 Kbyte or 2764 8 Kbyte RDM chips. When equip- 
ped with 2764 chips, the circuitry shown offers 32 Kwords of 
Read Only Memory. Whether this size is sufficient to accommo- 
date the software of the controller is as yet uncertain. Expan- 
sion of this ROM capacity is a very simple operation. Alterna- 
tively, operational software could be loaded from disk after 
start-up and stored in RAM. This way, only a bootstrap RDM 
would be needed. The consequence of this approach is a larger 
requirement for RAM. 



4.3.4. Address Decoding. 

Address decoding is covered in this paragraph as it is consi- 
dered to be an integral part of the memory system. 
Decoding is done in a way that places the RAM in the lowest 
region of the processor's memory map. This enables modification 
of the interrupt vectors located from 80H to 400H by the user. 
These vectors have to be loaded from ROM immediately after a 
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system reset . 

Since the 8086 CPU, ais well as the 8089 lOP, expects its reset 
vector to be in the high region of the loeinory map, the M3M 
memory is placed there . 

Rather than using conventional TTL decoders, programmable logic 
is used for address decoding. Using Programmable Array Logic 
introduces flexibility in that changing of the memory map can 
be obtained by simply replacing the PAL with a differently pro- 
graimaed version. Three PALs were used, one for RAM, one for ROM 
and one for I/O decoding . In figure 4.8. both methods are 
shown, the conventional way as well as the programmable way. 




Figure 4.8: Address decoding. 



4.4. Host Interface. 

As mentioned in chapter 3, a register-liXe approach was chosen 
for interfacing with the Host computer. Since the properties of 
the Host are not Xnown, it will depend largely on the applica- 
tion of the controller whether this kind of parallel interface 
is suitable. 

A block diagram of the interface hardware is given in figure 
4.9. below whereas a circuit diagram can be found in appendix 
A. 
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Figure 4.9: Interface block diagram. 



The interface hardware is made of two I/O channels, one for 
strobed I/O using a 8255 Programmable Peripheral Interface de- 
vice and the second for DMA trainsfers. 

Bi-directional I/O channel: Programmed to operate on a strobed 
I/O bi-directional ba^is, this 1/0 channel is used to transfer 
status and command information between controller and host. 
DMA transfer channel: Using two data transceivers, a 16 bit 
wide, bi-directional data channel is created between host emd 
controller for the purpose of transfering file data at maximum 
speed under lOP control. 

The Programmable Interrupt Controller (PIC) shown in figure 4.9 
should be considered as part of the processor system rather 
than the interface hardware. Its purpose is to allow external 
interrupts to the processor. The PIC is capable of placing a 
vector on the processors data bus after the first interrupt re- 
quest from the CPU. 

The relatively large number of lines between host and control- 
ler - 31 in all, excluding ground lines - stems from the facts 
mentioned below: 

- Parallel l/o 

- 16 bit wide data channel. 

- Seperate data and control/ status channel. 

Each of these facts add to the throughput capability of the 
interface and were introduced for that purpose. 
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4.5. Drive Control Onit Hardware. 

The hardware of the controller unit itself is a very essential 
part in the whole design. Generally, three possible implemen- 
tations of the functions mentioned in chapter two exist : 

1. Standard logic. 

2. Programmable logic. 

3. Single chip controller. 



4.5.1. Standard log ic . 

[>esigning a controller using small and medium scale integration 
logic chips results in a complex and fixed design. The PC board 
area is generally quite large and modifications, when necessary 
are difficult to make. Since this method is becoming extinct, 
no further attention was given to it. 



4.5.2. Programmable logic. 

A3 the next step towards modern controller design, the use of 
programmable logic chips to replace fixed logic should be con- 
sidered. When carefully designed and programmed, this method 
could yield a major improvement over traditional designs. How- 
ever, due to the rise of specially designed Winchester control- 
ler chips - see appendix C - this option was not studied. It 
might prove useful to do so. Refer also to appendix D for a 
slight impression of designing with progrannnable logic. 



4.5.3. Single chip controller. 

To avoid a large number of l6gic chips, high power consumption 
and little flexibility, which is typical of a random logic con- 
troller design, several semi-conductor manufacturers have come 
up with VLSI controller chips, capable of performing nearly all 
the functions of a disk controller. Appendix C gives an over- 
view of controller modules which are or will soon be available . 
In this report, the Microcomputer Systems Corporation (MSC) 
9000 Winchester Disk Controller Module was chosen. This choice 
was rather pragmatic since most information was available on 
this particular device. For this reason, the design described 
here is not claimed to be the optimal solution. 



MSC 9000 Controller Module. 

The Microcomputer Systems Corporation MSC 9000 Winchester Disk 
controller module contains most of the elements required for 
disk control as can be seen in the block diagram of figure 4.10 
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Figure 4.10: MSC 9000 controller module. 



Unfortunately, two different classes of Winchester disk drives 
have to be distinguished, those who have a built in data sepa- 
rator and Address Mark (AM) genarator/ detector and those who 
lack these facilities. The latter ones are generally found in 
the smaller and lower cost Winchester drives whereas high per- 
formance drives allways provide a built in data separator . 
Since the quality of the data separator determines to a large 
extent the data integrity of the drive, this is the only way a 
manufacturer can guarantee a certain reliability. 
Since the object of this graduation project was to design a 
universal Winchester Disk controller, a data separator and AM 
generator/detector will have to be incorporated in order to be 
able to accommodate low-cost drive types as well. For this pur- 
pose. Microcomputer Systems Corporation offers a module, label- 
led MSC 9100 to be used in conjunction with the MSC 9000 to 
create a complete controller. 

At this point a problem evolves. Appearantly the MSC philosophy 
did not foresee the use of its controller device in a universal 
controller environment . Two different types of MSC 9000 modules 
are offered, each slightly different in specifications and la- 
belled 9016 and 9056 respectively. 

Allthough the differences are marginal (refer to appendix B), 
it would be tedious to try to use either of these modules to 
handle both drive types. It would mean by-passing the MSC 9100 
to control Winchester drives with a built in data separator. 
Though possible, this option will not be covered in this report 
since it offers little additional insight. 

A block diagram of the controller hardweure is shown in figure 
4.11. The circuit diagram can be found in appendix A. 
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Figure 4.11: Controller hardware. 



4.5.4. Processor module interface. 

Since the HSC 9000' can be regarded as a processor system in its 
own within the hierairchy of the controller, it will have to be 
interfaced with the processor system in some convenient way. 
Two possible configurations can be considered: 

1 . SASI bus concept . 

2 . Special purpose interface . 



SASI bus. 

SASI stands for Shugart Associates System Interface, a byte- 
wide intelligent bus that interfaces host systems, like the 
processor system in this controller, to control units, like the 
HSC 9000. Currently this bus is being standarized by the ANSI 
X3T9.2 subcommittee under a new name, the Small Computer System 
Interface. Figure 4.12 shows the physical characteristics of 

this bus . „ , 
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Figure 4.12. SASI bus. 
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The major advajntage of using a bus structure like the SASI bus 
is the inherent possibility o£ incorporating several types of 
device controllers within the same controller unit. For in- 
stance, the same controller could be configured to drive any 
combination of Winchester drives, taipe units and floppy disks. 
Below this architecture is shown. 
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Figure 4.13: Bus architecture. 



Both flexibility and expandability are high using this ap- 
proach. However, according to Murphy's law, there has to be 
some disadvantage as well. 



Firstly, the use of a bus implies adaption of signal lines on 
two occasions, from processor system to bus and from bus to 
device controller. To put it another way, the incompatibility 
between processor system signal lines, device controller signal 
lines and bus signal lines requires extra hardware provisions 
as is illustrated by figure 4.14. 
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Figure 4.14s Bus adaptions, 
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Secondly, the SASI bus poses speed restraints on data treinsmis- 
sions thus obstructing the lOP from working at maximum speed. 



Special Purpose Interface . 

Osing a specially designed interface adapter circuitry to con- 
nect the MSG 9000 to the controller's processor system yields 
an optimal solution as far as data transfer speed is concerned. 
A circuit diagram of this hardware interface can be found in 
appendix A. 
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Figure 4.15. Special Purpose Interface. 

In order to explain its operation, it will be described in four 
sections : 

- Clock. 

- Data latches. 

- Communication protocol . 

- Reset circuitry. 

Clock . 

The clock signal required by the MSC 9000 is specified in 
accordance with the time diagram of figure 4.16. 
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Figure 4.16: MSC 9000 clock waveform. 
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Levels: To obtain the required voltage levels for the clock 
signal from a standard TTL output, the buffering cir- 
cuitry shown in appendix A is needed. 

Timing: The accuracy of the generated clock signal is deter- 



mined to a large extent by the crystal used. When 
using a 74lsl24 VCO chip for clock generation, a se- 
ries resonant fundamental mode crystal with a series 
resistance less then 200 Ohms is recommended. A 20 pF 
capacitor is placed in series with the crystal. Refer 
to figure 4 . 17 . 



Figure 4.17: MSG 9000 clock circuitry. 



Data latches. 

The MSG 9000 has a tri-state, active high data bus which ■ is 
used for communicating with both, the host processor and the 
disk drives. Externally driving this bus may only be done when 
the RDY and LDI signals from the module are both active. To 
obtain this, a data-input latch was added which is enabled only 
when the forementioned condition is satisfied . 
Bus buffering in the opposite direction is necessary as well, 
hence the other data latch clocked when RDY and DOUT are both 
active . Both latches introduce propagation delay times . 



Gommunication Protocol. 

The lowest level of communication between processor system and 
controller module involves the transport of command and data 
bytes. For this purpose, several interface signals are present 
which are listed below. 



MODBSY : MODai£ BUSY - indicates whether the control- 
ler is ready to accept a command or is still 
executing a previous command. 

CMDSCTT : GOMMAND SIGNAL - initiates a command transfer 
sequence . 

DREQ : GOMMAND REQUEST - request signal for next 
consnand byte . 

Ql : DATA REQUEST ON CHANNEL ONE - request Signal 



X-TAL 



VCO 



^ BUFFER 




for next data byte . 
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ACK J ACKNOWLEDGE - acknowledge command or data 
byte transfer. 



Both processor input lines MODBSY and CMDREQ are connected to 
the data bus through a tri-state buffer, selectable by the 
proper I/O address. This obliterates the need for an extra I/O 
port in the processor system. 

A timing diagram, illustrating the protocol of the communica- 
tion between processor system and controller module is given in 
figure 4.18. The flowcharts shown in appendix D, figure D8a and 
D8b can also be used as a reference. 



The hardware in which this protocol is largely implemented is 
fonned by a pulsed mode driven, asynchronous circuitry consis- 
ting of several D-f lip-flops and random logic gates . Though 
this approach is quite common in interface design and not dif- 
ficult, the result is a messy circuit, prone to errors caused 
by glitches. Alternatively, a synchronous circuit using pro- 
grammable logic could be used. Appendix D discusses this pos- 
sibility. 



Reset circuitry. 

In order to reset the controller module, a somewhat ackward 
reset signal is required on the controllers CLR input, as is 
shown below. 
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Figure 4.19: Reset timing. 



In order to obtain a CLR input timing like the one shown, a so 
called reset delay circuitry is needed, consisting of two one 
shots . 
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Figure 4.18: MSC 9000 INPUT/OUTPUT HANDSHAKE 
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Figure 4.20: Reset delay circuit. 



A positive going RESET signal triggers the first one-shot, 
causing a 10 msec long, low CLR to the module. Following this 
period, the second one shot is triggered, causing the CLR line 
to go low for another 1 usee. 



4.5.5. DMA transfer timing. 

Considering the importance of the DMA data transfers between 
processor system and controller module, a more detailed discus- 
sion of the timing involved was made. The results of this sur- 
vey, given below, are somewhat dissappointing . 



Data input timing. 

The MSG 9000 data bus, unfortunately is only 8 bit wide which 
leaves the choice 8/8 bit transfers or 8/16 bit transfers, the 
latter option by using the lOP's packing and unpacking facili- 
ties. Both possibilities are shown in the timing diagrams of 
figure 4.21 and 4.22 respectively. 



WID 8/8. 

WID 8/8 operation means data is fetched from memory on a byte 
by byte basis and sent to the controller module one byte at a 
time. The timing diagram of figure 4.21, shows this in detail. 
The situation shown here is a best case in which time delays, 
caused by the controller module are minimal, i.e. Tsl and Tip 
are 580 nsec and 248 nsec respectively. 

However, even with these minimal time delays, the data request 
(DRQl) for the next transfer cycle appears after the T4 state 
of the current transer cycle, yielding the insertion of 4 idle 
states, a delay of 4 x 200 nsec, 0.8 usee per transfer cycle. 
Thus, best case data transfers require 2.4 usec/byte. 
In a worst case situation, maximum values for Tsl and Tip, 20 
lOP clock cycles are needed for every trsuisfer cycle, yielding 
4 usec/byte. 
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Figure 4.21: MSC 9000 DATA INPUT TIMING (DMA) 
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Using the lOP's capeibility to unpack a 16 bit word into two 8 
bit bytes during a DMA transfer cycle, a situation as is shown 
in figure 4,22. arises. Again this is a best case situation. 
The unpacking operation requires four extra clock cycles be- 
tween two synchronous store cycles to allow the peripheral to 
remove its first data retjuest. Using this feature, the transfer 
of one word requires a minimum of 20 states, equivalent to 2 
usee per byte . Worst case values are 2 . 8 usec/byte . 



Remark . 

In spite of the MSC 9000 controller module's inability to 
handle 16 bit words, word/byte transfers can be used succes- 
fully to obtain a higher data transfer rate as compared to 
byte/byte transfers. However, the theoretically achievable 
meucimum transfer speed of 957 Kbyte/sec for data input to the 
MSC 9000 cannot be obtained. This dissappointing result origi- 
nates from the fact that communication between processor system 
and controller module is asynchronous . 



WID 8/8 WID 16/8 

min max min max 
SPEED 250 416 357 500 Kbyte/sec. 



Data output timing. 

In view of the results mentioned in the previous section con- 
cerning data input timing, only the 8/16 option was taken into 
consideration . 

Two sources of time delays can be discerned in figure 4,23: 

1. Four Idle states are inserted by the lOP between two syn- 
chronous fetch cycles. This delay is intended to allow the 
peripheral to remove its previous data request signal. In this 
case however, the DRQ is allready gone in time, so Idle states 
are not necessary. Unfortunately this feature is not optional 
so these four Idle states will have to be taken for granted. 

2 . The data request following the store cycle of the previous 
word, arrives at best during state T3 of the store cycle. As a 
result of this, the lOP inserts four Idle states immediately 
following the current store cycle. To avoid these Idle states, 
DRQ from the module has to be active before state T4 of the 
second fetch cycle. The minimum set-up times for Tsd and Tdp 
render this impossible. 

As a result of the facts mentioned above, a transfer cycle for 
one word requires at least 20 stat«s, yielding a maximum trans- 



73 



lOP CLK 



RDY 



1 



' Tl 



TI T2 T3 T4 i Tl T2 T3 T4 | Tl Tl Tl Tl Tl 12 T3 T4 Tl T2 T3 T4 



— fetch cycle 



— store cycle 1 — 



idle 



4x I 
Tl 1 Tl 



— store cycle 2 ■ — 



-J 

4k 



LDl 



DRQ 1 



ADDRESS. 



STROBE 



memory 



!< Tsl >;< — Tip 



1 



module 



module 



> — \ 1 




1 — ^ 









memory 



DATA 



MRDC 



lOWC 



Figure 4.22: MSG 9000 DATA INPUT TIMING (DMA) 
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Figure 4.23: MSC 9000 DATA OUTPUT TIMING (DMA) 
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f er speed of 500 Kbytes/sec . Assuming maximum values for Tsd 
and Tdp, a transfer cycle will require 28 states. (357 KB/s ) 



4,5.6. DMA termination . 

Any DMA transfer running on the lOP's I/O channels, can be ter- 
minated on one of the following conditions: 

- Terminate on single transfer. 

- Terminate on byte count . 

- Terminate on masked compare . 

- Terminate on external signal. 

Both channels will wait for a Data Request signal (DRQ) after a 
non-terminating transfer cycle. If this request never occurs, 
the DMA channel involved will wait indefinitely. Though such a 
hang-up on one channel does not affect the other channels 
operation - unless chained channel operation was selected - it 
will prevent the lOP from terminating the Task Block Program on 
the held up channel. 

To prevent this, the external terminate option has to be selec- 
ted on any DMA transfer operation since it is the only way to 
exit a hang-up situation. 

Using a Programmable Interval Timer (PIT) as a one shot, re- 
triggered after every DMA transfer cycle, will cause an exter- 
nal interrupt to the I/O channel after a programmable delay. 
Should a DRQ signal occur beyond a reasonable period of time, 
the external interrupt will cause the TBP to be resumed. A jump 
condition in the TBP can determine the occurence of an EXT 
interrupt and transfer control to the appropriate error hand- 
ling section. Refer to appendix A for the PIT connections. 



4.6. Drive interface . 

The interface circuit between drives and controller module 
consists of the following sections : 

- Data separator : The purpose of a data separator 

was explained in chapter 2 . As 
mentioned earlier, a MSG 9000 mo- 
dule was used for this purpose . 

- Precompensation : The precompensation circuitry is 

built around three D-FF' s clocked 
at a 40 Mhz clock frequency. Se- 
lect information for the multi- 
plexer is derived from the MSG 
9100 module . Refer to figure 4.24. 
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Figure 4.24: Precompensation. 



- Decoder s A decoder/multiplexer is used to 

decode the control information 
from the MSC 9000 for proper dri- 
ver and latch control. Refer to 
appendix B for the required de- 
coding scheme . 

- Latches ! Drive control signals axe latched 

from the module's data bus and 
transferred to the bus driver cir- 
cuits. Select information for 
these latches is derived from the 
MSC 9000 through the decoder 
/multiplexer. 



A block diagram of the controller disk drives interface cir- 
cuitry is shown in figure 4.25. 
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Figure 4.25; Controller Drive Interface. 
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4.7. Interface standards. 



The physical interface to the drives, created by the hardware 
concept described in the previous paragraph is known as the 
Floppy Extension Interface. Though not a universal standard, it 
is widely spread and found on most low cost 5 . 25 and 8 inch 
Winchester drives. In fact, until now no universal interface 
standard exists and due to several de facto standards pene- 
trating the market, the question whether or not such a standard 
will ever exist is justified. 

Appendix B contains a section concerning some of the interfaces 
currently in use or being suggested by the ANSI . 
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Chapter 5. SOFTWARE DESCRIPTION. 



5.1. Introdution . 

The software required to operate an intelligent controller like 
the one covered in this report is quite eactensive. When desig- 
ning software of this scope, it is generally considered good 
policy to divide it into functional sections and develop a mo- 
dular structured software package, rather than a large bulk of 
code , An attempt to make such a functional division was made in 
the block diagram of figure 5.1. 
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Figure 5.1: Software block diagram. 



The following sections are discerned. 

Host Protocol Handler: Handles all communication be- 
tween Host computer system and controller. 

Disk Protocol Handler: Randies all communication be- 
tween Disk controller module and the controller's pro- 
cessor system. 

Disk Operating systems Handles file management amd ma- 
nipulation . 

Error Handler: The error handler is responsible for 
dealing with unforeseen occurencces within the control- 



ler software. After entering this software section, a 
known and defined state has to be reached from which 
point the controller can resume proper operation. 

Prior to describing each of these software modules, the con- 
troller's initialization phase will be discussed. 



5.2. Initialization. 

After a power-up of the controller, it will receive an auto- 
matic reset signal, bringing both the controller's processors 
in a defined state and resetting the controller module as well. 
As the 8086 CPU is strapped as a master processor, it will 
start executing from memory location FFFFO H were it should en- 
counter an intersegment direct jump which target is the star- 
ting location of the actual initialization routine. At this 
stage all interrupts are disabled. 

The tasks performed by the initialization routine are listed 
below in sequential order. 

1. CPU initialization. 

2 . lOP initialization . 

3. Peripheral initialization. 

4. RAM test. 

5. Interrupt vector field initialization. 

6. Controller module initialization. 

7. File management administration set up. 

8 . Interrupt enabling . 

After execution of this sequence, the controller is ready to 
receive and execute its first command. 



5.2.1. CPU initialization. 

Initializing the CPU jneeuis its segment registers have to be 
given a predetermined value. After a reset, the code segment 
register has the value FFFF H, the instruction pointer 0000 H. 
Thus the first instrution is fetched from location FFFFO H as 
stated before. As a result of the intersegment direct jump in- 
struction located there, the code segment register as well as 
the instruction pointer are given a new value, transferring 
control to the initialization program located in ROM. 
The stack segment register is set to the top of stack, the 
stacksize being restricted to 756 words, due to the expected 
low degree of interrupt nesting. 

The Data segment is used by the DOS to store its tables and 
pointers . The size chosen ( 7 Kword ) may prove to be insuffi- 
cient and can be expanded easily. 

Finally, the Extra segment register is initialized, pointing to 
the area of the controllers workspace where file data is 
stored . The memory map created thus can be found in figure 5.2. 
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Figure 5.2: Memory map. 



5.2.2. lOP initialization . 

The next phase in the initialization process, is to configure 
the lOP for its task. The lOP enters a HALT state after recei- 
ving a reset signal. To start its initialization sequence, it 
has to receive a channel attention (CA) from the CPU. During 
this CA, the select line is used to indicate whether the lOP is 
to function as master or as slave processor. In this case, the 
lOP will be a slave processor ( SEL= high). Subsequently the lOP 
will request and obtain control over the system bus which it 
will assume to be eight bits wide. The SYSBUS field located at 
memory location FFFF6 will inform the lOP about the actual bus 
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width, 16 bits in this case. The SYSBUS field is peurt of the 
system configuration pointer block, located from PFFPe through 
PPPPB H in ROM. This block also contains a pointer to the sys- 
tem configuration block itself where the lOP can find the sys- 
tem operation command, containing information about the 
request/grsmt mode and the physical I/O bus width. Furthermore 
the lOP stores the value of the channel Control Block (CCB) in 
an internal register. As a result of this, the CCB cannot be 
relocated unless another system reset is given. 
This completes initialization of the lOP. To signal the host, 
the Channel 1 Busy Plag, set to FP H by the CPU prior to ini- 
tializing the lOP, is cleared smd control of the system bus is 
redirected to the CPU. 

The CCB contains two identical sections, one for each channel. 
In each section, a busy flag, indicating whether the corres- 
ponding channel is active or not, a Channel Command Word (CCW), 
indicating the channels mode of operation and a Parameter Block 
pointer ( PB ) are present . The PB contains the task block poin- 
ter plus any other parameters the Task Block Program (TBP) 
requires for proper operation. 

At this stage the CCB is not initialized yet since it can be 
done by the CPU at any time before staxting an I/O program. 
Figure 5.3 shows the lOP initialization sequence, figure 5.4. 
the various control blocks involved and their locations. 



5.2.3. Peripheral initialization. 

In order to configure the controller for its task, the periphe- 
ral chips present in the system need be initialized properly. 
This entails programming each peripheral to function in the de- 
sired mode. 



Prograimnable Peripheral Interface. : 

The PPI is programmed to operate in mode 2 on channel A and C. 
Thus strobed I/O is obtained through these channels. Port B can 
be configured for itKide operation, either input or output. 
Programming is done by writing the proper control word in the 
peripheral's control register. 

Programmable Interrupt Controller . : 

As the PIC was designed to accommodate both 8080/8085 and 8086 
/8088 processor systems, careful attention should be given to 
proper initialization of this peripheral since both systems 
require different interrupt handling procedures. Initialization 
is performed in two phases; 

- Initialization Command Words. A sequence of 2,3 or 4 control 
words is stored in the PIC. In this particular application, 
three ICW's are needed to confa^ure the PIC as follows: 
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- Single controller. 

- Edge triggered interrupt . 

- Interrupt vector field starts at location 080 Hex. 

- No slave interrupt controller. 

- 8086/8088 mode operation. 

- No special end of interrupt . 

- Non buffered mode. 

- Not special fully nested mode . 

After loading the ICW's, the PIC is ready for operation. Fur- 
ther additional options can be programmed subsequently by wri- 
ting Operation Command Words (OCW) 

- Operation Command Words. Three OCW's axe required to select 
the desired mode of operation: 

OCWl: The first OCW is used to set an interrupt mask on 
the eight interrupt lines. Only those lines that auce 
not masked off will cause an interrupt request to the 
CPU. 

0CW2; The second OCW specifies whether a rotating 
priority scheme is used which is not the case here . 
0CW3: The third OCW enables the user to apply the PIC 
in a polled interrupt environment, rather than a 
vectored interrupt one. This feature is not used. 

This terminates the initialization of the PIC. It is now 
capable of detecting interrupts on eight levels, each having a 
different priority. IRO, having the highest priority, is used 
to service host requests, providing the lOP is not executing a 
DMA transfer. In the latter case, the interrupt will remain 
pending until the CPU regains control of the system bus. 



Programmable interval Timer. : 

After a system reset, all counter modes au:e undefined. Initia- 
lization is done by writing the appropriate sequence of contol 
words to the PIT. In order to configure the PIT for retrig- 
gerable one-shot operation as indicated in paxgraph 4.5.6., 
counter and counter 1 au:e to be programmed in mode 1. during 
DMA tranfers. However, ais long as no DMA transfer is in pro- 
gress, both counters have to be inhibited. For this purpose, 
both counters are programmed to mode 0. This will force the 
outputs to remain low as long as the gate inputs, connected to 
the data request outputs of the lOP remain low. Thus no EXT 
interrupt is generated. It is the responsibility of the Task 
Block Porgram that initiates the DMA transfer to reprogram its 
corresponding counter to mode 1 and loading it with a suitable 
count value. After proper termination of the DMA transfer, the 
corresponding timer has to be disabled again. 
Timer 3 remains unused. 
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5.2.4. RAM test. 

A RAM test is performed to verify correct operation of the con- 
troller's workspace and to determine its size. Testing is done 
by an algorithm like the one shown below. 

BEGIN PROCEDURE RAMTEST 

VAR ADDR, PATTERN, TEST : INTEGER. 

END : BOOLEAN. 

ADDRi-OOO H; PATTERN :=*5 5 55 H;TEST:-AAAA H ; END : =»FALSE 

WHILE NOT END DO 

MEM( ADDR ) : =»PATTERN ; 

IF MEM(ADDR) NEQ PATTERN THEN END:=TRUE 

ELSE BEGIN 

SHIFTLEFT MEM(ADDR) 
IF MEM(ADDR) NEQ TEST 
THEN END:=»TROE 
ELSE ADDR:=ADDR+1 

PI 

END 

FI 

OD 

END (RAWPEST) 



5.2.5. Interrupt Vector field initialization . 

The interrupt vector field is located in RAM from location H 
to OFE H according to Intel convention. The contents of this 
field can be loaded form the controller's RDM by a REP MOVSW 
instruction which moves an entire data block from memory to 
memory. The value of these interrupt service routine pointers 
can be altered during program execution. 

5.2.6. Controller module initialization. 

After reception of the hardware reset signal, the controller 
will signal the processor system by asserting its ready line. 
Issuing a DIAGNOSTIC command to the controller module will 
cause it to perform an internal check. The result of this check 
routine can be obtained by means of a STATUS command. Refer to 
paragraph 5.4. 
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Subsequently, the CPU can configure a Task Block Program for 
the lOP to read track zero of drive 0. The information thus 
obtained should at least contain pareuneters such as: 

- No of heads. 

- No of drives . 

- No of tracks per drive . 

- Physical block size. 

- No of blocks per track. 

- Index list pointer. 

- Root directory pointer. 

- Free space table pointer. 

This information is stored in the controller's workspace for 
future reference. 



5.2.7. File management administration set-up. 

Initialization of the Disk Operating System means resetting all 
relevant pointers such ais those that point to the current open 
file table which is empty at this stage, the active I-node 
table which is loaded with the Index node of the Hoot directo- 
ry. Also pointers into the controller's data buffer are 
cleared . 

The Root directory is fetched from the disk since the user will 
have to refer to it initially. Figure 5.5. shows the situation 
as it occurs after these steps . 
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5.2.8. Interrupt enabling . 

At this stage in the initialization process, the controller is 
ready to receive and execute conmtands from the Host . As these 
commands are given on an interrupt basis, the interrupt enable 
flag of the processor has to be set the final step. 



USER LIST 



supervisor 



pointers to user 
open fi e tables 



OPEN FILE TABLE 




ACTIVE I-LIST 



1 » 


root directory 
index node 




ROOT DIRECTORY 






1 » 






Figure 5.5: Initial state. 
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5.3. Host Protocol Handler. 



As stated before, the Host Protocol Handler performs all commu- 
nication between Host Computer and Controller. This communica- 
tion is bi-directional and involves the exchange of the follo- 
wing information : 

- Commands from Host to controller. 

- Status from controller to Host . 

- Pile data between controller and Host. 

The protocol by which this communication takes place will be 
described shortly but prior to that, a brief discussion concer- 
ning synchronous and a-synchronous I/O will have to decide for 
either of these forms of communication, a choice that has con- 
siderable impact on the protocol itself. 

Synchronous I/O. 

Synchronous I/O meeuis every request from the Host is serviced 
immediately by the controller. During this service request, the 
Host waits for the result of his request before continuing pro- 
cessing. Figure 5.7. illustrates this. 



HOST 



CONTROLLER 



WAIT 



REQUEST 



SERVICE 



RESULT 



_v 

I 

I 

I 

I 



Figure 5.7: Synchronous I/O. 



A-synchronous I/O. 

In the case of asynchronous I/O, service requests from the Host 
are queued by the controller. After issuing a service request 
to the controller, the Host continues processing. Upon termina- 
tion of a requested service, the controller interrupts the Host 
to transmit the result. Furthermore the controller has to in- 
form the Host of the request to which this result belongs since 
Host requests are not necessairilly serviced in incoming order. 
Using A-synchronous I/O, multiple service requests from the 
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Host can be buffered and serviced in an order best suited for 
the controller. Refer to figure 5.8. 



HOST 



RE01 



V 



REQ2 



REQ3 



QUEUE 



SCHEDULER 



RESULT 2 



RESULT 1 



RESULT 3 



CONTROLLER 



\1/ 

■SERVICE 2 



■SERVICE1 



ERV1CE3 



Figure 5.8: A-synchronous I/O . 



The major advantage of synchronous I/O is its relative simpli- 
city, no request queueing, no scheduling, no interrupts to the 
Host. On the other hand, the host is inactive during the time 
his request is being serviced by the controller, leading to a 
decreased performance of the Host . 

A-synchronous I/O entails scheduling of requests by the con- 
troller's Host Protocol Handler. Furthermore, the Host might 
need the results of his request before being able to continue 
its current process . Thus the apparent advantage of parallel 
processing could be deceiving. On top of that, the Host has to 
keep track of outstanding requests and the order in which he 
receives the results from the controller. 

BcLsed on these considerations, synchronous I/O was chosen 
whereby the Host interrupts the controllers current activity by 
issuing a service request and subsequently waits for the re- 
sult. Figure 5.9. illustrates the controller's control flow. 
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HOST 

PROTOCOL 
HANDLER 
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( ^RETURN ) 
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HANDLER 



Figure 5.9: Control flow. 



5.3.1. Layer model. 

The problems involved with cononunicat ion protocols between com- 
puter systems, which is what we are dealing with here, are ex- 
tensive. Mo attempt is made in this report to present a univer- 
sal solution to communication protocol problems. The approach 
chosen here is somewhat related to the ISO Open Systems Inter- 
connection reference model allthough some modifications were 
made. One of these modifications is the reduction to four 
rather than seven layers as can be seen in figure 5 . 10 . 



APPLICATION LAYER 



PRESENTATION LAYER 



TRANSPORT LAYER 



DATA LINK LAYER 



Figure 5.10: Protocol layer model. 
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5.3.2. Applicat ion Layer . 



The application layer acts as an intermediary between the con- 
troller's Disk Operating System and the Host Protocol Handler. 
This interaction is bi-directional. The DOS calls the applica- 
tion layer as a subroutine whenever it wants to transfer status 
information or file data to the Host. The application layer in 
return, signals the reception of a command request or a data 
file from the Host to the DOS. This signalling is done by means 
of a flag rather than on interrupt basis. 

The information obtained by the application layer, originates 
from the layer underneath. Communication between the diverse 
layers in the model is performed stricktly through system memo- 
ry. 

Figure 5.11. illustrates the interaction between IX3S euid Appli- 
cation layer. 



i 

PROCESS 



TEST 

MESSAGE 

FLAG 




PROCESS 
MESSAGE 



INPUT 



PROCESS 



MESSAGE 
BLOCK 



A PPL. LAYS 
CALL 



TEST 
RESULT 




CONTINUE 



OUTPUT 



Figure 5.11: DOS- Applicat ion Layer interaction. 
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5.3.3. Presentation Layer. 

The task of the presentation layer is to arrange the incoming 
and outgoing data into a fixed format to avoid mis-interpreta- 
tion. To this extent, three different types of so called I/O 
blocks axe distinguished: 

- Command Block. 

- Status Block. 

- Data Block. 



Command Block. 



COMMAND CODE 



USER ID 



FILE NAME 



RECORD NUMBER 



DATA FIELD LENGTH 



CONTROL FIELD 



COMMAND CODE: Block identifica- 
tion. 

USER ID: user identification. 
FILE NAME: String of characters 
terminated by an ETX symbol spe- 
cifying the file. 

RECORD NUMBER: Record to be ac- 
cessed within file. 
DATA FIELD LENGTH: Length of data 
involved . 

CONTROL FIELD: Error control in- 
formation . 



The length of a coromand block is variable and depends largely 
on the file reference information, i.e. filename or path name. 
The other fields within the command block are of a fixed 
length . 



Status Block. 



STATUS CODE 



USER ID 



STATUS FIELD 



CONTROL FIELD 



STATUS CODE: I/O block identi- 
fication . 

USER ID: User identification. 
STATUS FIELD: String of charac- 
ters terminated by an ETX symbol 
containing the actual status in- 
formation . 

CONTROL FIELD: Error control in- 
formation . 



The status block contains infonnation concerning the controller 
, in particular any errors that occured as a result of the exe- 
cution of a user command. The length of this I/O block is 
determined by the information contained in the status field. 
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Data Block. 

The fonnat of a data block is similar to that of a status block 
in that it has the same fields. In a data block however, file 
data is contained in the last field. 



DATA CODE 



USER ID 



□ATA FIELD 



CONTROL FIELD 



DATA CODE: I/O block identifi- 
cation . 

USER ID: user identification. 
DATA FIELD; String of characters. 
CONTROL FIELD: Error control in- 
formation. 



A Data block allways follows after either a command or a status 
block. For this purpose, the command and status code fields 
contain a flag indicating whether the block is followed by a 
data block or not. 



5.3.4. Transport Layer. 

The transport layer serves a dual purpose: 

1. Receiving command and data blocks. 

2. Sending status and data blocks. 

The condition imposed on this transport of I/O blocks, is that 
it is done error- free. To this extent, error checking and re- 
transmission is performed. In case of failure, an error status 
signal is generated, signalling the presentation layer. 

1. Receiving. 

The Host can interrupt the controllers current activity by 
writing to the peripheral interface port. Providing the lOP is 
not active, i.e. the CPU is running, it will receive an inter- 
rupt from the Command/Status I/O port. As a result of this, an 
interrupt service routine is called which initializes the lOP 
to perform the required task block program. This TBP proceeds 
with the following steps: 

+ Acknowledge the interrupt and disable further inter- 
rupts . 

+ Read and interpret the contents of the PPI . 

+ Transfer control to the required software routine. 
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What routine this should be depends on the value of the first 
byte sent by the Host. Three possibilities exist: 

1. Command code. 

2 . Status code . 

3 . Data code . 



Command routine. 

After receiving a commaind code, the lOP polls the PPI to obtain 
two further bytes, indicating the length of the I/O block the 
Host will sent over the Data channel. Based on this information 
,an area in the controllers workspace is allocated as I/O buf- 
fer. Subsequently a DMA channel is prepared and a DMA transfer 
from host to controller is initiated. 

The actual DMA transfer is performed by the physical layer des- 
cribed in the next paragraph. 

After termination of the DMA transfer, a checksum is calculated 
and compaired with the information contained in the I/O block's 
control field. In case of a mismatch, a retrajismission is 
requested . 

The Host, after termination of the DMA transfer, waits for a 
message from the controller through the command/status channel 
to verify whether the I/O block was received correctly. If not, 
the entire block is sent again. This process repeats itself un- 
til a retry counter at the host decrements to zero after which 
the attempt is aborted. 



Data routine. 

As the result of a succesful I/O block transfer, the lOP task 
block program checks the flag in the I/O block's command code 
field to see whether a Data block follows. If so, the data 
block is transfered to the controller acccording to the same 
principle as a command block. 



Illegal routine. 

Upon detection of a unknown or illegal code sent by the Host, 
the communication is broken off. A message byte is sent to the 
Host informing it of the fact that the code received was not 
legal and the communication process at the controller was 
aborted. Hence the Host will have to try again. 

In figure 5.12 an attempt was made to draw a flow-chart of the 
receive routine in the transport layer. 

After returning from the interrupt service routine, the CPU 
will resume its previous activity. Whatever process is running 
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Figure 5.12: Transport Layer receive routine. 



on the CPU, it will frequently have to check the I/O buffer 
flag for reception of a cowmand or data block. Refer to figure 
5.13 for this polling sequence. 




BACKGROUND 



K^lOflai 

'f 




T 



FOREGROUND 



Figure 5.13: Controller DOS polling. 
2 . sending . 

The routine which transfers 1/0 blocks from controller to host 
is allways called from the presentation layer. It executes the 
following sequence of actions : 



- A status code is written to the PPI which places it 
on the command/ status bus. 

- The status register of the PPI is polled to determine 
whether the host has accepted the status code. 

- Two furter bytes are sent according to the same prin- 
ciple which contain the length of the I/O block to be 
transfered. 

- DMA channel is prepared. 

- DMA transfer is executed. 

- The status register of the PPI is polled to determine 
whether the host has received the I/O block properly. 
If not, the sequence is repeated. 



The flowchart of figure 5.14 shows this sequence. 

Allthough the process described above is simple enough, there 
is one specific point of interrest which deserves special at- 
tention. At several points in the routine, busy waits are 
introduced to verify correct acceptation and reception of cer- 
tain bytes by the PPI. Circumstances may occur which will pre- 
vent these busy wait loops from terminating, causing a hang up 
of the controller. In order to prevent this, time out facili- 
ties have to be provided for. 

Unfortunately, no external interrupt -generated by an Interval 
Counter for instance- can be given to the lOP unless it is per- 
forming a DMA transfer which is typically not the case during a 
busy wait loop. 
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i ~ 
set parameter 
block. 

I 

channel att 
TOP 



Task block 

program 

SEND. 



write status 
code to PPI 

3: 




write two I/O 
block length 
bytes to PPI 

; 



prepare DMA 
channel 





DMA transfer 




read PPI status 
register 


NZ—^^ta"^ 



jresent 



read PPI data 
register 




return to 
CPU. 



Figure 5.14: Transport Layer sent routine. 
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Rather than transferring the sent routine from executing on the 
lOP to the CPU which can be interrupted, a software time out 
like the one shown in figure 5 , 15 will have to be added . The 
software time out is created by a counter which is decremented 
after every unsuccesful attempt . As soon as the counter decre- 
ments to zero, an exit from the routine is made, specifying the 
cause of the exit to the calling routine. Between successive 
attempts, a delay is introduced, proportional to the time esti- 
mated for the host to respond. 



load retry- 
counter with, 
initial value 



read PPI status 
register 








decrement 
retzy counter 










'retry cntr"' 
sauals 



set error 
flag. 



return to 
CPU. 



Figure 5.15: Time out. 



5.3.5. Data Link Layer, 



The data link layer is responsible for the actual transfer of 
bytes or words. For this purpose it has two independent l/o 
channels available as described in chapter 4. One channel 
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( command/ St at us channel) uses strobed I/O, supported by the 
Programmable Peripheral Interface ( PPI ) and transfers command 
and status information. The second channel transfers the I/O 
blocks mentioned previously under DMA. 

The communication protocols of both channels are shown in the 
state diagrams of figure 5.16 and 5.17 respectively. 



99 




HOST STROBED INPUT GONTROLLER 



CJBF=T / \ 0BF=F/ 

/ \ ACK-F 



rdata\ /data^ 
lavailah/ (accept 



ACK-T ACR=T 
HOST STROBED OUTPUT CONTROLLER 

Figure 5 . 16 : 




HOST DMA INPUT CONTROLLER 




Figure 5 . 17 ; 



5.4. Disk Protocol Handler. 

As an opponent towards the Host protocol handler, this section 
of the software is responsible for the communication between 
the controller's processor system and the Winchester disk con- 
trol hardware. As a logical consequence of this, the protocol 
used for communicating between the two is determined primarily 
by the MSG 9000 controller module . 

Two types of messages are invloved in the communication process 
, commands and data. 

5.4.1. Commemds . 

The MSG 9000 supports eleven commands which can be divided in 
commands that don't cause additional data transfers and com- 
mands that do. All commands, including those that don't require 
disk access, conform to the eight byte format shown below. 

BYTE 1 : GOMMAND CODE. 

BYTE 2 : DRIVE SELEGT. 

BYTE 3 : CYLINDER ADDRESS, MSB 

BYTE 4 : CYLINDER ADDRESS, LSB 

BYTE 5 ! HEAD ADDRESS. 

BYTE 6 { SECTOR ADDRESS HI 

BYTE 7 : SECTOR ADDRESS LO 

Commands that do not require the full eight bytes have to be 
adjusted by the insertion of pad bytes to maintain this eight 
byte command length convention. 



5.4.2. Data. 

Certain commands, like read and write commands, are followed by 
a data transfer. The amounth of data involved in the transfer 
is related to the nature of the command. Read and Write com- 
mands yield data transfers of one sectorlength . A Status com- 
mand only requires the transfer of a single byte whereas a Sec- 
tor Interleave command is followed by a 21 byte transfer. 
Thus the routine that issues the command should also initiate 
the data transfer. 
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Figure 5.18: MSC 9000 command table. 



5.4.3. Task Block Program . 

The task block program (TBP) that impleinents the relatively 
simple Disk Protocol Handler is shown in the flowchart of 
figure 5.19. Calling this routine after configuring the correct 
parameter block (PB) results in issuing a connnand to the MSC 
9O00 and subsequently transferring data if applicable. Figure 
S . 20 shows the format of the parameter block required for this 
routine . 



TASK POIIWliR/CHAMEL 
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Figure 5.20: Disk Protocol Handler PB, 
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Figure 5.19: Disk protocol handler TBP. 
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The flowchaxt is thought to be self explaining. Note that no 
error conditions are detected by this routine. Therefore it is 
considered wise to perform a status read of the MSC 9000 after 
every command. Such a status read can be done by issuing a Sta- 
tus command to the module which will then transfer one status 
byte. As this is a noirmal command, the same routine could be 
used. It would be easier however to devote a special TBP for 
this task. Refer to figure 5.21 and 5.22 for a flowchart of 
this TBP and the corresponding PB. 
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Figure 5 . 22 . Status read PB . 



5.5. Disk Operating System. 

The Disk Operating System is defined as the collection of the 
following sub-systems : 

- Command Handler. 

- Free Space Administration. 

- File management. 

Each of these sub-systems will have to be executed by the 8086 
CPU assisted where necessary by the lOP. A possible implemen- 
tation of this DOS will be given in the form of flow diagrams 
in the following paragraphs. 



5.5.1. Command Handler. 

Section 3.4. gave an overview and functional description of the 
commands supported by the DOS. Each of these commands will be 
discussed seperately. 



Control flow. 

After succesful completion of the initialization sequence, the 
controller will enter an idle state. During this idle period, 
the message flag of the Host Protocol Handler will be checked 
frequently to see whether the Host has sent a conmiand. If so, 
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Figure 5.21: Status request TBP . 



the command will be fetched from its I/O commsmd block and be 
interpreted by the Command Handler. 



CREATE routine. 

Upon entering this routine, the name of the file to be created 
is fetched from the parameter block and a lineair search in the 
directory is performed to determine whether the file exists or 
not. If not, space is allocated by invoking the Free Space Ad- 
ministration routine. An index node for the file is created and 
added to the I-list. Updating of the directory finishes the 
create routine . 



OPEN routine. 

The open routine performs two functions. Firstly it checks 
whether the file to be opened exists and whether the user has 
legal access rights, secondly it creates access to the file by 
adding its index node to the user's open file table. Further- 
more the window - a pointer to the next record of the file to 
be read - is initiated to point to the first record of the 
file. 



WRITE routine . 

A write operation adds a record to the end of the file. In 
order for a write to be legal, the window of the file has to be 
at the end of the file. The file name is fetched from the PB 
after which access rights are checked. It may be necessary to 
allocate free space in which case the FSA routine is called. 
The actual write operation is done by calling the Disk Protocol 
Handler routine . After a succesful write operation, the corres- 
ponding Index node is updated and the window incremented. 



READ routine. 

The read operation is to a large extent analogous to the write 
routine. Reading is done at the position pointed to by the win- 
dow, one record at a time. The data read from the disk is 
placed in a buffer in system memory. After creating the proper 
I/O block, the Host Protocol Handler is called to transfer the 
contents of the buffer to the Host. 



SEEK routine. 

Whenever the user wants to do a random record read, he has to 
perform a seek operation, positioning the window at the record 
he whishes to read. This is done by the SEEK routine. Speci- 
fying the record is done by a number. Note that the SEEK rou- 
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Figure 5.23i Control Flow. 
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Figure 5.24i Create routine. 
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Figure 5.25: Open routine. 
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Figure 5.26i Write routine. 
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Figure S.27i Read routine. 
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Figure S.28: Seek routine. 



tine does not imply a read operation. 



INSERT routine . 

The insert routine is complex in nature in that it implies dis- 
tortion of the sequential order in which the records of a file 
are stored on the disk. Nevertheless it gives the user the very 
powerful option of adding a record to a file at an arbitrary 
position, thus enabling updating and extending of files. 
An INSERT command has to be preceeded by a SEEK command to 
position the window at the desired position in the file. To al- 
low for insertions in the sequential storage structure, one has 
to introduce a new type of pointer, the indirect pointer. The 
alternative to this method is alter the pointers following the 
position of the record to be inserted. This would involve ex- 
tensive data movements and would thus be time consuming. 
By using indirect pointers, the only penalty paid is a slightly 
slower access to records of a file beyond an insertion point. 
Figure 5.29 illustrates this method. 
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Figure 5.29: Record insertion. 



Insertion of records implies a fair amounth of administration 
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Figure 5.30i Insert routine. 
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and results in a slower access response. It would be good poli- 
cy to try and restrict the use of this option to a selected 
group of users . 

ERASE routine. 

The user caji remove a record from a file at an arbitrary posi- 
tion within the file. To do this, he has to perform a seek 
operation to the record he wishes to remove. Upon calling the 
erase routine, the pointers to the disk blocks containing the 
data of that record are set to deleted. This means these poin- 
ters cu:e still present but not accessable. The blocks turned 
free by the removal of the record are registered as free blocks 
again by the Free Space Administration. 



CLOSE routine. 

Calling the close routine results in the removal of the speci- 
fied file from the open file table. As such, this routine is 
quite similar to the open routine. 

DELETE routine. 

The delete routine removes the directory entry of the specified 
file from the directory list. All blocks on the disk containing 
the data of this file are returned to the Free Space Admini- 
stration. Before returning control to the command handler, the 
deleted file name with its corresponding I node are added to 
the recover file. 



RECOVER routine. 

Whenever a user decides to try and recover a previously deleted 
file, the command handler will call the recover routine. After 
confirmation of the fact that the file to be recovered was ac- 
tually deleted, the recover file is read into workspace. 
Whether it can be recovered or not depends on its presence in 
this file. If it is, a comparison is made between the I node 
contents and the Free Space Administration to see if the blocks 
previously occupied by the file aure still free. If not, reco- 
very is impossible since the data of the file was overwritten. 
If the blocks in question are still free, they may still con- 
tain the original data allthough there is no certainty. By 
creating a new I node the data of the file are made available 
to the user. It is the user's responsibility to verify the 
contents of the recovered file. 
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Figure S.31i Erase routine. 
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Figure 5.32: close routine. 



(begin) 



fetch file name 
from PB 

i 



search in directory 







fetch I node 








check access 
rights 




x^ccess^ 




clear directory 
entry | 



CAiL: PSA 
re-allocate 
free blocks 



NO PILE 
ERROR 



NO ACCESS 
ERROR 



mark pointer to 
I node as deleted 



store file namB 
and I number in 
recover file 



(end ) 



Figure 5.33: Delete routine. 
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Figure 5.34: Recover routine. 






DIKLIST routine. 

The DIRLIST routine starts with inspecting the parameter block 
for a file name. If no file name is present, it assumes the 
user wants a listing of the root directory and makes a copy of 
the root directory' s I node in an area of workspace called the 
Current Index Node (CIN). If a file name was specified, a check 
is performed on the file type of that file to see whether it 
actually is a directory type file. If not, an error condition 
occurs . 

The I node which is present in the CIN is subsequently sceuined 
to obtain all file names and file types it points to. This in- 
formation is stored in a buffer. When the end of the directory 
has been reached, the contents of the buffer is transfered to 
the host by calling the Host Protocol Handler. 



RENAME routine . 

The renaming of a file is quite a simple operation. Some checks 
are built in. Firstly to verify whether the file to be renamed 
exists at all, secondly whether the new name supplied by the 
user was not previously used for naming another file. 



ENQUIRY routine. 

The explicit function of the enquiry routine is to fetch the 
information stored in the Index node of a file and msOte this 
information available to the Host. For this purpose, the direc- 
tory is searched until the specified file name is found. The 
information present in the Index node is transfered to a buffer 
which is subsequently sent to the Host . 



5.5.2. Free Space Administration. 

The Free Space Administrattion entails a dual function; 

1. Registration of used and free disk blocks. 

2. Allocation and re-allocation of blocks. 



Registration. 

For the registration of free and occupied blocks, a bit map ap- 
proach was chosen as explained in chapter 3. 

Since every position within the bit map corresponds to a physi- 
cal block (or sector) on the disk, a translation from bit posi- 
tion to disk address must be made. 

The bit map is made of an array of consequetive words, starting 
with word number zero. A bit map address consists of a word 
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Figure 5.35i Dlrllst routine. 
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number and an offset into that word. A disk address is made of 
a head, cylinder and sec±or number. 




HEAD 2 



Figure 5.37: Bit map. 



The mapping procedure is illustrated by figure 5.37. Given the 
position of a bit within the bit map as P,Q where P equals the 
word number and Q the offset value, the disk address can be 
calculated as such; 

Head number = P div M 

Cylinder number = ((P-P div M)* 16 + Q) div M 
Sector number = ((P-P div M)* 16 + Q) mod M 

where tf = (no. of cylinders * no. of sectors/track )/16 
M =» no. of sectors/track. 



Reversely, the bit position of a block within the bit map can 
be calculated from the disk address H,C,S by; 

P=(H*N+C*M+S) div 16 
Q=(H*N+C*M+S) mod 16 
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To give an impression of the size of such a bit map, aji example 
of a medium sized Winchester drive is given below. 



Capacity 

Mo of heads 

Mo of cylinders 

Mo of sectors/track 

Mo of bytes/sector 



34 Mbyte formatted. 



4 

1024 

17 

512 



Total number of blocks 
Bit map size required 



69632 

4352 words 



Thus the bit map would occupy 9 blocks on the disk in this 
particular case. 

Mote however that when the number of sectors per track is not a 
power of two, the surithmetic operations involved in mapping 
between bit map address and disk address becomes quite complex. 

Re-allocation . 

Blocks being turned free, probably as a result of the deletion 
of a record or a file, have to be registered as such. This 
means converting the corresponding disk addresses to bit posi- 
tions within the bit map and setting these bits to indicate - 
free blocks. A check to see whether the block turned free was 
actually occupied is also performed in the process. Refer to 
figure 5 . 38 . 
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Figure 5.38: Re-allocation. 
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Allocation . 

Allocation of disk space to a file or record is done by request 
from the command handler. A few things should be considered 
when designing an algorithm for this purpose. 

- Assigned space should be contiguous as much as possi- 
ble in order to minimize head movements and thus to 
reduce average access time. 

- space assigned to an existing file for the purpose of 
extending it should be as close to the old file posi- 
tion on the disk as possible for the same reason. 

- Garbage collection, i.e. moving files across the disk 
to create contiguous free space, should only be done 
when disk saturation occurs . 

- Generally, newly allocated blocks should be at the 
end of the previous allocation, i.e. the disk should 
be filled from the lower tracks upwards. This is to 
prevent tedious fitting in of blocks in small area' s 
previously turned free by the deletion of records, 
when there is still sufficient contiguous free space 
on the upper tracks. 

In order for the allocation routine to meet these recpairements, 
it requires knowledge of the following information: 

1. Number of blocks to be allocated. 

2. Position of the last allocated block. 

3 . File extension or new file . 

4. In case of a file extension, position of the last 
block of the file. 
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Figure 5.39: Allocation routine PB. 
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Figure 5.40: Allocation routine. 
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Calling the allocation routine results in the return of a list 
of disk addresses which can be assigned to the record or file 
they where requested for. This list is stored in workspace at a 
location pointed to by a pointer supplied by the calling pro-, 
cess . 

Communication between calling process (command handler) and 
allocation routine is performed through a parameter block. The 
format of this PB is shown in figure 5 . 40 . 



5,5.3. File Meuiagement . 

The File Management section is made up of a database, contain- 
ing all the lists and tables required for the file access 
mechanism, and a set of routines that operate on this database. 
The list and tables mentioned were described in chapter 3 pre- 
viously. The set of routines described below, offers additional 
service to the process that wishes to use the information con- 
tained in the database . 



Access right control. 

Using the information stored in a file's index node regarding 
the identity of the file's user cuid owner in conjunction with 
the kind of access requested, the access rights can be checked. 
Three types of access axe possible, read only, read/write amd 
execute only. Also, three levels of access authority are dis- 
tinguished, owner, user and group. Hence the format of the 
access information field in the I node is as such: 

OWNER USER GROUP, 

exc r/w ro exc r/w ro exc r/w ro 

XXX XXX XXX 



Index node create routine. 

When called by the create routine of the command handler, this 
service routine configures and stores a new Index node using 
the information supplied by the calling process. 

Search file name. 

This routine searches through a list or table, depending on the 
process which called it, and when found returns a pointer to 
the location where the filename was found. When not, an error 
message is returned. Normally this search would be lineair 
since no ordering of file names takes place. 
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5.5.6. Error Handler . 



A3 can be seen in the flowcharts presented in this chapter, 
several error conditions can occur at various points during 
program execution. The purpose of the error handling routine is 
to minimize the effects of these error conditions and to pre- 
vent them from obstructing further operation of the controller. 

Error conditions are divided into three categories: 

1. Recoverable errors. 

2 . Dser errors , 

3 . Fatal errors . 



5.6.1. Recoverable errors . 

Recoverable errors eure those errors whose effects can be elimi- 
nated by either trying to obtain the same result through an 
alternative way or by simply retrying the operation that caused 
the error. 

Recoverable errors frequently occur in communication processes 
where the loss of some information caused by external inter- 
ference results in an error condition. By retsarting, the same 
error will usually not occur again. Most of the errors that can 
be avoided or compensated for this way, are covered locally in 
the software in the software routines. Refer in particular to 
the frequent occurence of time-out loops in the host and disk 
protocol handler routines. Only after a predetermined number of 
retries, a fatal error is signalled. 

Another type of semi-recoverable error is the one that occurs 
when requested free disk space is not available, the so called 
MO SPACE ERROR. Three possibilities exist to overcome this 
problem : 

1. Garbage collection. By seeurching through the file 
management table's, all areas of the disk that are 
not in use axe turned free. In the process, all 
files are rearranged so as to avoid small unsused 
gaps between them. 

2. Change volume. Though disk space is usually reques- 
ted on a specific volume, it could in some cases be 
diverted to another where more space is available. 
Note that this has considerable consequences for the 
file administration information. 

3. Return to Oser. By returning to the user, it becomes 
his responsibility to create free space by deleting 
one or more files or records. Thus, a status I/O 
block is configured and sent to the host . 
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5.6.2. User errors . 

A considerable percentage of errors falls into this category. 
User errors axe caused by the issuing of non-executable com- 
mands by a user. Upon detection of such an error condition, the 
controller aborts its current process, typically the execution 
of a user command, and creates a status I/O block, informing 
the user of the kind of error he made. Armed with this infor- 
mation, the user can take the appropriate action. 

User errors are; PILE NOT OPEN 
NO PILE 
NO RECORD 
NO ACCESS 
NOT EOF 
CREATE 
NO RECOVER 
NOT DELETED 
NO DIRECTORY 
ILLEGAL NAHE 



5.6.3. Patal errors. 

As the name suggests, these kinds of errors result in a situa- 
tion the controller cannot handle. Generally this means a hard- 
ware failure occured in the controller itself or in the Host's 
communication section. 

Patal errors are: DEVICE ERROR, controller module malfunction. 

COMMUNICATION ERROR, Time-out occured during 

DMA transfer or busy wait. 
HOST ERROR, Host does not respond correctly 

Upon detection of a fatal error, the controller enters an idle 
state . 
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Chapter 6. CONCLUSIONS AND RECOMMENDATIONS. 



Due to the fact that the controller module used in this design 
was not available at the time, no prototype could be built and 
tested. Therefore, no experimental data or test results can be 
presented here. Nevertheless, the design presented in this re- 
port is considered to be a feasible solution to the interface 
problem associated with the application of Winchester Disk 
Drives . 



6.1. Conclusions . 

The most predominant advantage of the design at hand is the 
high degree of service it offers to the host computer. The com- 
mand level supported by this controller related to file manipu- 
lation is compaxable to that of a high level language like Pas- 
cal. 

From a dsigner's point of view, the use of an integral control- 
ler module like the MSC 9000 eliminates the traditional design 
problems of the disk controller unit hardware. The penalty for 
this is a lower degree of flexibility in respect of interface 
standards and drive types that can be accommodated. 
Additionally, a controller conform this concept is inherently 
expensive compared to those that lack a DOS facility. Thus it 
application is restricted to small and medium sized mini-compu- 
ter systems, rather than micro-systems. 

The use of the DNIX operating system as a guide-line for desig- 
ning the controller's DOS proved advantaguous since UNIX offers 
a straightforward file structure and storage organization. Un- 
fortunately it will be impossible to implement a UNIX compati- 
ble operating system in the controller since UNIX uses special 
files for I/O operations. This requires the neccesary file 
organization information to be present at the host which is ex- 
actly what should be avoided by using an intelligent 
controller. 

The aspects mentioned above should be considered seriously when 
deciding for an approach like the one described here. 



6.2. Recommendations. 

Some recommendations can be made to enhance the design for 
future follow-up of the project. 

Firstly, the introduction of the Intel 80186 single chip compu- 
ter during this project, might prove to be a serious alterna- 
tive to the co-processor system of 8086 and 8089. Allthough the 
DMA controller imbedded in the 80186 is not as powerful as the 
lOP, it could prove to offer sufficient service for this appli- 
cation . 
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The suggestion to use programmable logic ( FPGA' s/PAL' s ) instead 
of a controller module as is done here, is repeated. Also, it 
would be wise to use controller modules that support a standard 
interface to there host e.g. the SASI interface bus . 

Finally, it would be advantaguous to allow the controller di- 
rect access to the host's memory. Allthough the idea of buffer- 
ing in the controller is not a bad idea in itself, the extra 
work of moving information from this buffer to the host could 
be avoided by granting the controller direct access to the host 
memory. A condition for this approach is the rewuired compati- 
bility between controller and host bus system. In particular a 
dual port memory system at the host would suit this applica- 
tion. 
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Appendix B. MSG 9000 OA.TA SHEET. 



MSC-9000 SERIES 
DISK ORIENTED I/O PROCESSORS 
PRODUCT SPECIFICATION 



The MSC-9000 is a series of modules which incorporate 
75% of the circuitry required to interface to small Winchester 
disk drives. There are two modules, each with identical 
features but with functional differences to accommodate 
either the Memorex 101 , or Seagate Technology ST-506disk 
drive. The functions incorporated within each module of the 
MSC-9000 series allow high level tasks to be communicated 
with it, achieving sophisticated control of the disk drive with 
minimum additional circuitry. Signals are provided allowing 
the easy implementation of simple interface circuits to 
control up to 4 disk drives. The MSC-9000 simplifies and 
handles most of the burdens associated with implementing a 
disk drive controller. 

There are twelve separate commands which the Module 
will execute. Each of these commands requires multiple 8 
bit bytes to fully specify the task. 

Seek Read Sector Write Long 

Recalibrate Write Sector Status Report 

Diagnostic Read Long Format Track 

Set Interleave Write Alt. Sector Write Check 



FEATURES 

■ Alternate sectoring for defect skipping. 

■ Variable interleave for data transfer rate tuning. 

■ Sophisticated error correction ensures data integrity, 
detecting up to 22 bit burst-errors and correcting up to 
1 1 bit burst-errors. 

■ Full Sector Data buffer allows flexible data rates without 
affecting data transfer integrity. 

■ Automatic position verification to ensure data base 
integrity. 

■ Self-diagnostics assures easy maintainability. 

■ Proven technology for attaining high reliability. 

■ Compact Module ensures easy integration into strin- 
gent space restrictions. 

■ Low power consumption (4W typical). 

■ High level modularity ensures high maintainability. 

■ Universality assures easy mtegration for most system 
requirements. 

■ Supports up to 4 disk drives. 

■ Automatic Retries 



MODULE 
POWER ANO 
CLOCKS 



CLK 



VCC 



GROUND 



ERROR 
CORRECTION 



TO HOST 
INTERFACE 



RESET 



STROBE 



BUSY 



READY 



DATA 
BUFFER 



CONTROL 
PROCESSOR 



COMMAND MODE 



LOAD DATA IN 



SL512 



DATA OUT 



V 



DISK 
ORIENTATION 
MANAGEMENT 


INDEX 


POSITION 


^ AMD 








READ DATA 


DISK 
DATA 
MANAGEMENT 


WRITE DATA 


READ GATE 


WRITE GATE 





DISK 
STATUS 

ANO 
CONTROL 



DATA BUS 



PLO CLOCK 



0C1 



OCO 



OCVALIO 



DATA OUT 



> 



TO DISK 
INTERFACE 



Rgure 1 
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PIN CONRGURATION 



LDI 


O 1 


40O 


vcc 


DOUT 


O 2 


39 


vcc 


UNUSED 


3 


38 


0TA7 


CLR 


O 4 


37 


DTAO 


AMD 


O 5 


36 O 


DTAl 


AMD 


6 


36 


DTA6 


SL512 


O 1 


34 O 


DTA5 


DCO 


O 8 


330 


DTA2 


DCl 


9 


32 O 


DTA3 


UNUSED 


O'o 


31 


DTA4 


UNUSED 


O" 


30 O 


PLO 


UNUSED 


012 


290 


INDX 


cmd' 


Ol3 


28 


WDTA 


UNUSED 


Oil 


270 


WGTE 


UNUSED 


015 


260 


BOTA 


RDY 


016 


25 


RGTE 


asY 


on 


24 O 


PSTN 


DCV 


0'8 


230 


UNUSED 


CLX 


Ol9 


22 O 


STB 


GNO 


O20 


21 O 


GNO 



No 


Symbol 


Name 


I/O 


Function 


1 


ldT 


Load Data In 





Active low output. When RDY is active this signal should 










be used to Gate Host data onto the data busfor input to the 










module. 


2 


DOUT 


Data Out 





Active low output. Indicates the data bus contains valid 










data output from the module to be stored in the host 










interface when RDY is active or the disk interface when 










DCV Is active. 


4 


CLR 


Clear 


1 


Active low input. Clears the Module. 


•5/6 


AMD 


A.M DETECT 


1 


Active low input. Address mark detect from data separator. 


7 


SL512 


Select 512 


— 


512 Data Bytes per Sector when = 1, 256 when = 0. 


8 


DCO 


Disk Control 





Active high output disk interface control signals. These 


9 


DCl 


Disk Control 1 





signals are encoded for which disk status or control In- 










formation is on the data bus when DCV is active. See 










Table 1. 


13 


CMD 


Command 


1 


Active low input. Requests the Module to enter command 






Mode 




mode to enable giving it the command descriptor on the 










data bus. Command mode will only be entered when 










module is not busy (BSY - 0). This signal can be reset 










anytime after the module accepts the first byte, it must be 











inactive before the module returns to Not Busy. 


16 


RDY 


Ready 





Active low output. Signifies when data can be transferred 










and Strobe can be activated. 


17 


BSY 


Busy 





Active high output. Signifies when module is processing 










(or acting on) command descriptor given to it. When low 










signifies idle and ready to accept command descriptor. 


18 


DCV 


Disk Control 





Active low output. Indicates when the disk control signals 






Valid 




DCO and DCl contain valid control signals to define the 










use of the Data Bus. See Table 1. 


19 


CLK 


Clock 


1 


4 MHz Clock input. 


20, 21 


GNO 


Ground 




D.C. Power Ground 


22 


STB 


Strobe 


1 


Active high input. Strobes data in or out of module. May 










only be set when RDY is active. 


"24 


PSTN 


Position 


1 


Active high input. Pulse for defining the rotational posi- 










tion of the disk. Sector Pulse in MSC-9016 from Memorex 

101. 


25 


RGTE 


Read Gate 





Active high output. Read Gate for disk drive. 


26 


RDTA 


Read Data 


1 


Active high input. NRZ serial read data from disk drive or 










data separator. 


27 


WGTE 


Write Gate 


o 


Active high output. Write Gate for disk drive and data 










separator. 


28 


WDTA 


Write Data 





Active high output. Write Data for disk drive or MFM 










encoding circuit. 


29 


INDX 


Index 


1 


Active high input. Index pulse from disk drive. 


30 


PLO 


PLO Clock 


1 


Active high input. PLO clock from disk drive or data 










separator for Strobing read and write data. 


31-38 


DTAX 


Data X 




Active High Tri-State Bidirectional 8 bit Data Bus. NOTE: 










This bus should only be driven from outside the module 










when RDY and LDI or DCV are active. See Table 1. 


39, 40 


VCC 


Power 




+5 Volt D.C. Power. 


•Not used on MSC-9016 for MRX101 


— Pull up to VCC through IKO Resistor for -9016. 


••Not used on MSC-9056 for ST-506 


—Tie to ground for -9056. 


Note: 


Unused Pins Must Be Left Open. 
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COMMAND SET DEFINITIONS 



CODE '0' SEEK — The seek command moves the heads 
to the specified absolute cylinder. The disk 
must be formatted. 

'1' READ ONE SECTOR— The read one sector 
command transfers one sector of data from 
the disk to the host system. During this com- 
mand, the Module positions the heads (im- 
plied seek), verifies the ID field, transfers the 
sector data to the module, and checks and 
corrects data errors prior to transferring the 
data to the host. 

'2' WRITE ONE SECTOR— The write one sector 
command transfers one sector of data from 
the host to the disk. During this command, the 
Module transfers one sector of data from the 
host to the internal buffer, positionsthe heads 
(implied seek), verifies the ID field and If 
proper, writes the data to the disk. 

'3' FORMAT ONE TRACK— The format one track 
command initializes all ID and data fields for 
the specified track. The data field is initialized 
with a preset pattern of B6DB6D. The head 
parameter is used to select the head of the disk 
prior to formating, the cylinder parameter is 
used to write the ID field. 

'4' RECALIBRATE— The recalibrate command 
positions the heads at track 00 on the disk. 

'5' STATUS — The status command sends one 
byte of status information to the host. The 
status represents the results of the previous 
task. 

'6' READ LONG — The read long command trans- 
fers one sector plus thefour ECC (Error Correc- 
tion Code) Bytes from the disk to the host. 
During this command, the module positions 
the heads (implied seek), verifies the ID field, 
transfers the sector data to the module, and 
then transfers the sector plus ECC Bytes to the 
host. The module does not try to correct the 
data field if an ECC error occurs during the 
read. This command can be used to verify the 
ECC function of the module. 



CODE 'T WRITE LONG— The write long command 
transfers one sector plus four ECC Bytes from 
the host to the disk. During this command, the 
module transfers one sector plus the ECC 
Bytes from the host to the internal buffer, posi- 
tions the head (implied seek), verifies the ID 
field, and writes the data and ECC to the disk. 
This command can be used to verify the ECC 
function of the module. The appended ECC 
polynomial should be (X^^ + + X'^ + X" + 
X^ + 1). 

'8' WRITE ALTERNATE SECTOR -This com- 
mand is used to reassign a defective sector to 
the alternate location on the track. During this 
command the module formats the entire track 
and initializes all data fields with B6DB6D. The 
specified Sector is assigned as defective and the 
alternate sector is assigned as a replacement. 
Note that if the rest of the track already contains 
data it must be preserved by reading all sectors 
and re-writing all sectors after the alternate 
assignment (this command) is executed. 

'9' SET INTERLEAVE— This command transfers a 
block of data into the Module which represent 
the interleave table of logical to physical as- 
signments. After CLEAR or diagnostic com- 
mand, the Module defaults to no interleave 
until this command is executed. 

'A' WRITE CHECK — The command is identical to 
the READ Sector command, without any data 
transferred. It can be used to verify the 
previously written data can be read without 
ECC errors. 

'B' DIAGNOSTIC — This command causes the 
Module to execute a self-test; checking its 
internal processors, data buffers, ECC cir- 
cuitry, and Program memory. A STATUS 
command can then be performed which will 
give the results. If this command does not 
complete within 2 seconds the Module has a 
defect which prevents communication. This com- 
mand will leave the module in a clear state. 



NOTE: Four retries will automatically be invoked if an 
error is encountered during any of the following 
operations: 

• Position Verification (Seeking) 

• Target Sector Verification 

• Hard ECC Error on Read Sector 

• Write Alternate Sector 
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COMMUNICATION 



TABLE I— Data Bus Contents with DCV = 
DC1, DCO 





00 


01 


10 


*11 




Output Head 


Output Drive 


Input Status 


Reset 




and Control 


Select 




AM Detect 




(DOUT = 0) 


(DOUT = 0) 




(DOUT = 0) 


MSC-9016 


Do 


Head 


Select 


Track 00 


N/A 


D, 


Head 1 


Select 1 


Write Fault 


N/A 


Da 


Head 2 


Select 2 


Seek End 


N/A 


D, 


Head 3 


Select 3 


Drive Ready 


N/A 


D4 


Step 








Ds 


Direction Select 








D, 


Fault Clear 


















MSC-9056 


Do 


Head 


Select 


Track 00 


None 


D, 


Head 1 


Select 1 


Write Fault 


None 


D, 


Head 2 


Select 2 


Seek End 


None 


D3 


Head 3 


Select 3 


Drive Ready 


None 


D4 


Step 


Write Address Mark 




None 


D= 


Direction Select 






None 


D5 




! 
1 




None 


D, 


Reduce Current 


t 




None 


*This function is not used in the IV1SC-9016 



(Maximum numbers of cylinders = 1024) 



All commands are sent to the Module using 8 Bytes of information over the Module Data Bus (BIT = LSB) in the 
following format. 

Byte 1 Command Code 

Byte 2 Drive Select (one of four) 

Byte 3 Cylinder Address — Most Significant Byte 

Byte 4 Cylinder Address— Least Significant Byte 

Byte 5 Head Address 

Byte 6 Sector Address 

Byte 7 Sector Count Hi 

Byte 8 Sector Count Low 

If a command does not require the full 8 Bytes, then Pad Bytes must be included to maintain the 8 Byte message 
length. After the task is sent to the Module, data will be transferred (in or out) when the task is executed. 

The Task Bytes are represented as follows: 



Byte 


Task Bytes 


Dy 


De 


Ds 


D4 


D3 


D2 


Di 


Do 


1 


Command Code 


1 











23 


22 


2' 


20 


2 


Drive Select (one of four) 














D4 


D3 


D2 


Di 


3 


Cylinder Address (MSB) 


Cl5 


Cl4 


Cl3 


Cl2 


Cii 


Cio 


C9 


Cs 


4 


Cylinder Address (LSB) 


Cy 


Ce 


Cs 


C4 


C3 


Ca 


Ci 


Co 


5 


Head Address 














Hs 


H2 


Hi 


Ho 


6 


Sector Address 


Sy 


Se 


Ss 


S4 


S3 


Sa 


Si 


So 


7 


Sector Count Hi 


























8 


Sector Count Low 























1 



I = Retries can be inhibited by setting bit 7 in command byte. 
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MSC-9000 COMMUNICATION SEQUENCE SUMMARY 





Data Bytes 




CMD 


DRV 


CYL 


CYL 


HD 


SCT 


SCT 


SCT 


Number 


In/Out of 


COMMAND 


CODE 


NBR 


MSB 


LSB 


ADR 


ADR 


HI 


LOW 


of Bytes 


Moduls 


SEEK 





X 


X 


X 














READ 


1 


X 


X 


X 


X 


X 


X 


X 


N 


OUT 


WRITE 


2 


X 


X 


X 


X 


X 


X 


X 


N 


IN 


FORMAT 


3 


X 


X 


X 


X 




X 


X 






RECALIBRATE 


4 


X 


















STATUS 


5 
















1 


OUT 


READ LONG 


6 


X 


X 


X 


X 


X 


X 


X 


N+4 


OUT 


WRITE LONG 


7 


X 


X 


X 


X 


X 


X 


X 


N+4 


IN 


WRITE ALT 


8 


X 


X 


X 


X 


X 










SET INTERLEAVE 


9 
















S 


IN 


WRITE CHECK 


A 


X 


X 


X 


X 


X 


X 


X 






DIAGNOSTIC 


B 





















(X) represents a task byte is required. ( — ) represents a Pad 



Byte is required. 


STATUS CODE TABLE 


(N) is the number of Data bytes per Sector which can be 


CODE 


MEANING 


selected to be 256 or 512. 


00 


No Error 




01 


Invalid Command 




02 


Drive Not Ready 




03 


Seek Timeout (2 Seconds) 




04 


Invalid Track 00 indication from disk drive 




06 


All ID Fields Bad on Track 




06 


Target Sector Not Found 


(S) is the logical to Physical interleave table with the 


07 


No Sector Found and ID ECC Error on Target Sector 


number of bytes equal to the number of Sectors per track. 


08 


Position Error (Seek Error) 




09 


Defective Module or Support Signals 




OA 


Drive Fault Active 


Byte Interleave Table Contents 


OB 


Index/Sector Timeout 


Physical location of logical Sector 


OC 


Command Parameter Error 


1 Physical location of logical Sector 1 


00 


Uncorrectable ECC Error 




IX 


Correctable ECC Error 




20 


Write Alternate Error 


20 Physical location of logical Sector 20 


21 


Invalid Alternate Sector Assignment 




22 


Alternate Already Assigned 




23 


Direct Access to Alternate Sector 


37 Physical location of logical Sector 37 


24 


Defective processor 




26 


Defective Buffer Memory 




26 


Defective ECC Circuitry 




27 


Defeaive Program Memory 




28 


Illegal Sector Pulse during diagnostic 




29 


Illegal Interleave Table Parameter 




NOTE: X is the length of the burst error which can be 1 to B 


Sectors Per 256 Bytes/ 512 Bytes/ 


to note if the correction span was 1 to 1 1 bits. 







Track Sector Sector 



Module Type MSC-9016 38 21 

MSC-9056 32 17 
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MSC-9000 



MSC-9000 SERIES D.C. CHARACTERISTICS 



Ta = 0°C to +50°C; Vcc = +5V ±5% unless otherwise specified. 





Limits 




Test 


Parameter Symbol 


Min Typ(1) 


Max 


Unit Conditions 


Input Low Voltage Vil 


-0.5 


0.8 


Volts 


Input High Voltage Vih 


2.5 


Vcc + .5 


Volts 


Output Low Voltage Vol 




0.45 


Volts loL=Max 


Output High Voltage Vqm 


2.4 


Vcc 


Volts loH = Max 


Vcc Supply Current Ice 


0.8 


1.4 


Amps 


Note 1: Typical values for Tj= 


25°C and nominal Vcc- 










OUTPUT CURRENT (MIN) 






Signal 


High Level loH (mA) 




LOW Level lot (mA) 


LDI, DOUT 


160mA 




2.5mA 


RDY 


200 




3.2 


DCV 


400 




8.0 


BUSY, WGTE, WDTA 


400 




2.8 


RGTE 


400 




5.6 


D0-D7 


80 




.90mA 


DCO, DC1 


140 




1.36 




INPUT CURRENT (MAX) 






Signal 


High Level Iuh (mA) 




Low Level l^n. (mA) 


CMD, AMD, SL512 


10 




io(mA) 


CLR 


90 




1.7 




120 




.88 


PSTN, INDX 


50 




2.0 


CLK 


160 




2.1 


STB 


80 




1.5 


PLO 


60 




1.2 


RDTA 


40 




.8 



Ta = 25°C; Vcc = OV OUTPUT CAPACITANCE -50pf max 

Absolute Maximum Ratings* 

*T, = 25°C 



Operating Temperature 
Storage Temperature 
All Input Voltages 
All Output Voltages 
Supply Voltage Vcc 



0°C to +50='C 
-40°C to +125°C 
-0.5 to +7 Volts 
-0.5 to +1 Volts 
-0.5 to +7 Volts 



Comment: Stress above those listed under "Absolute 
Maximum Ratings" may cause permanent damage to the 
device. This is a stress rating only and functional opera- 
tion of the device at these or any other conditions above 
those indicated in the operational sections of this specifi- 
cation is not implied. Exposure to absolute maximum 
rating conditions for extended periods may affect device 
reliability. 



NOTE: Failure to observe conventional precautions during storage, handling, and usage, in order to avoid exposure to 
excessive voltages or static charges may affect device reliability. 
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MSC-9000 



TIMING CHARACTERISTICS 



Host Data Input To Module 



RDY 



LDI 



STB 



■ 125 nsec typ. 







MIN 


TYP 


MAX 


UNITS 


Tlo 


LDI LOW TO DATA ENABLE 









NS 


Tos 


DATA SETUP FROM STROBE 






100 


NS 


ToH 


DATA HOLD FROM LDI HIGH 


5 




115 


NS 


TsL 


STB HIGH TO LDI HIGH 


580 




1235 


NS 


Tls 


LDI HIGH TO STB LOW 







210 


NS 


T,P 


LDI HIGH TO LDI LOW 


248 




748 


NS 


Max 


DATA INPUT RATE 






957 


KB/ sec. 




(DISK WRITE) 










T,s 


LDI LOW TO STB HIGH 









NS 



Host Data Output From Module 



RDY 



DOUT 



STB 



■ 375 nsec typ. 



<x><xx xx x 



MIN TYP MAX UNITS 



ToA 


DATA VALID FROM DOUT LOW 




75 


NS 


Tos 


DOUT LOW TO STB HIGH 







NS 


Tso 


STB HIGH TO DOUT HIGH 


560 


1175 


NS 


Tqh 


DATA VALID FROM DOUT HIGH 


32 




NS 


Tos 


DOUT HIGH TO STB LOW 




270 


NS 


Top 


DOUT HIGH TO DOUT LOW 


485 


915 


NS 


Max 


DATA OUTPUT RATE 
(DISK READ) 




873 


KB/ sec. 
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MSC-9000 



TIMING CHARACTERISTICS 



Reset Timing 



Vcc 



-Tpclr- 



■TwCLR ■ 



CLR 



TpcLR = 10 MILLISEC (MIN) 
TwcLR=1 mSEC (MIN) 



Clock Timing 



VlH 
ViL 












— ^ 


TcLK — *■ 





TCYL 



• TcLK ■ 



TcLK =110NSEC{MIN) 

TcYL = 250 MSEC ±1% 

ViH = Vcc - 0.8V 

ViL =0.8V 
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MSC-9000 



TIMING CHARACTERISTICS 



Disk Control Timing 



DCV 



DCO, DCl 



DOUT 



DO-07 
(OUT) 



X 



VALID 



1 



VALID 



Tdcvl 

Toes 

Tdch 

To 

Tdh 



625 NS 

212 NS (MINI 

51 NS (MIN) 
30 NS (MAX) 

52 NS (MIN) 



X 



Disk Data Timing 



PLOCLK 



RDTA 



WDTA 



TcYL = 192 NS (MIN) (50%±10% DUTY CYCLE) 

Thus = 20 NS (MIN) 

I ROH = 20 NS (MIN) 

Two = 55 NS (MAX) 
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MSC-9056 FORMAT 













ID FIELD ^ 


-« DATA FIELD »► 


AM GAP1 


SYNC1 6AP2 COM CYLH CYLL HEAD SEC FLAG ALT ECCI 


GAP3 


SYNC2 GAP4 DATA ECC2 


GAPS 



FIELD 


FIELD DESCRIPTION 


# OF BYTES 


AM 


ADDRESS MARK 


4 


GAP1 


ZERO BYTE GAP 


9 


SYNC1 


ID SYNC BYTE 


1 


GAP2 


ID ZERO BYTE GAP 


2 


COM 


ID COMPARE BYTE 




CYLH 


CYLINDER HIGH (MSB) 




CYLL 


CYLINDER LOW (LSB) 




HEAD 


HEAD n 




SEC 


SECTOR # 




FLAG 


FLAG BYTE 




ALT 


ALTERNATE SECTOR 




ECCI 


ID ECC BYTES 


4 


GAP3 


ZERO BYTE GAP 


16 


SYNC2 


DATA FIELD SYNC BYTE 


1 


GAP4 


DATA FIELD ZERO BYTE GAP 


2 


DATA 


DATA FIELD 


256/512* 


ECC2 


DATA FIELD ECC BYTES 


4 


GAPS 


INTER-RECORD ZERO GAP 


14/43* 



256 bytes = 32 sectors/track 
512 bytes = 17 sectors/track 



*256 BYTE SECTOR/512 BYTE SECTOR 
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Mechanical Dimensions 



PIN 1 





.020 max 




.021-,026 OIA PIN 
TIN-LEAO PLATED 



Weight = 300 grams max. 



All Dimensions in Inches. 



RECOMMENDED MOUNTING METHODS 

1 . ) Wave or Hand Soldered w/ .042 Min. Hole Dia. 

2. ) Sockets w/ Mechanical Mounting to PCB. 
Sockets; Augat #8134-HC-6P2 

8134-HC-6P3 
Cambion #450-3703-01 
450-3983-01 



ORDERING INFORMATION 

Model Disk Drives Accommodated 

MSC-9016 Memorex-101 , Fujitsu 2301 
MSC-9056 Seagate Technology ST-506 
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Appendix C. WD CONTROLLER MODULES OVERVIEW. 



C.l Controller haxdwaxe. 

The layer between the Winchester and the software drivers (see 
figure 1.1) is formed by the controller hardware. The control- 
ler hardware is responsible for executing functions involving 
data-conversion, AM detection and status and control hamdling. 



I Host interface 
I protocol . 



I File managment 
! 



I software 
I drivers 



1 controller 
I 



I drive interface 
I protocol . 



1 Winchester 
I drives 



Figure C.l. 



Two approaches exist when designing the controller hardware . 
The first and hitherto most commonly used approach is the use 
of conventional TTL logic , usually in fairly large quantities . 
Such a design can be customized to meet all the requirements of 
the user. The price for this is a laxge number of chips, high 
power consumption and little flexibility. 

In order to overcome these problems, several manufacturers have 
come up with functional modules, capable of performing many of 
the functions required for drive control. Using such modules 
lowers the amount of external hardware and simplifies control- 
ler design. Since this is a fairly recent development, scarce 
information is available on these modules. Nevertheless an at- 
tempt is made to describe the functional features of some of 
them. 
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C.2. MSG 9000. 



The MSG 9000, manufactured by Microcomputer Systems Corporation 
, incorporates 75% of the circuitry required to interface to 
small Winchester disk drives. Two models exist, each with iden- 
tical features but with functional differences to accomodate 
either the Memorex 101 or Seagate Technology 506 disk drive . 
The functions incorporated within the modules allow high level 
tasks to be communicated with it, achieving sophisticated con- 
trol of the disk drive with minimum additional circuitry. Up to 
four drives can be serviced by one module. Refer also to appen- 
dix B. 

The following lists all the commands the module is capable to 
execute . 

- Seek Track. 

- Recalibrate. 

- Diagnostic. 

- Set Interleave. 

- Read Sector. 

- Write Sector. 

- Read long. 

- Write Alternate Sector. 

- Write long. 

- Status Report. 

- Format Track. 

- Write Check. 



Commands are transfered in a 8 byte format as such: 



Byte 1: Command Code. 

Byte 2: Drive Select. 

Byte 3: Cylinder Address, 

Byte 4: Cylinder Address, 

Byte 5: Head Address. 

Byte 6; Sector Address. 

Byte 7: Sector Count Hi. 

Byte 8: Sector Count Lo. 



Commands that don't require the full 8 bytes like Status re- 
port, use pad bytes to maintain the 8 byte length, 
sector size is software selectable to 256 or 512 bytes/sector. 
Error bursts of up to 11 bits can be corrected and 22 bit burst 
errors will be detected allowing high data integrity. 

Data transfers. 



The module transfers data in blocks that equal one sector on 
the disk. Both programmed I/O and DMA transfer techniques may 
be used. A built-in sector buffer compensates for speed dif- 
ferences between controller and host. Maximum data-rates using 
DMA are set to 957 Kbytes/sec for input to the module, 873 
Kbytes for output. 

Unfortunately the data-bus from the module is only 8 bits wide. 
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Unfortunately the data-bus from the module is only 8 bits wide. 
Using a 8089 I/O processor would limit the transfer speed to 
625 Kbytes/sec since the 8089 requires eight clock cycles to 
perform a memory to port or port to memory transfer. With a 5 
Mhz clock this requires 8*200 nsec = 1.6 microsecs. A 16 bit 
wide data-bus would permit maximum transfer rates to be achiev- 
ed. 

MSG 9100. 

When controlling low-cost drives like the ST506, external cir- 
cuitry for datar-separation and AM detection is required, as 
mentioned before. The MSG 9100 was developed to be used in con- 
junction with the MSG 9000 to perform precisely these func- 
tions. It comprises a clock generator, NRZ to MFM converter , 
addres mark detector/ generator, phase locked loop and MFM to 
NRZ converter. Gontrol signals for precompensation are also 
available from this module . 

Interface . 

The floppy extension interface is used for interfacing between 
drives and controller. A universal bus is available for host 
communication . 



G.3 Western Digital 1010. 

The Western Digital WD 1010 is a 40 pin package, single chip 
Winchester controller, capable of controlling an interesting 
class of low-cost 5.25 and 8 inch Winchester drives. The chip 
contains MFM encoder/decoder, address mark detector, high speed 
shiftregisters, write precompensation and write splice avoidan- 
ce logic. External sector buffering, phase locked MFM read 
clock and high frequency detection must be added externally. 

The command level is not as high as is the case with the MSG 
9000. A brief survey is given in the table beneath. 



Data transfers to and from the disk are made at a 5 Mbit/ sec 
speed which is compatible with most low-cost 5 . 25 inch drives . 
The use of an external FIFO sector buffer enables DMA transfers 
at any desirable speed, (limited by the FIFO and or DMA logic, 
not by the controller chip. ) As with the MSG 9000, the extended 
floppy interface is supported while the interface to the host 
is universal. 



-Restore 
-Seek 



automatic seek to track 000. 

seek specific track. 

perform a sector read. 

perform a sector write. 

scans track for ID field. 

writes all necessary address marks 

and data marks on a track. 



-Read sector 
-Write sector 
-Scan ID 



-Write format 
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C.4. National Semiconductor chip set. 

Only very recently. National Semiconductor Corporation euinoun- 
ced a chipset, capable of supporting a large number of dif- 
ferent Winchester drives. Depending on the sophistication of 
the drive to be controlled, one or more of the chips are need- 
ed. The four chips in the set are: 

- Pulse detector, converting einalog pulse signals into 
digital pulses. 

- Data separator, generating a read clock and decoding 
standard MFM data. 

- MFM data encoder. 

- Formatter, serializer, deserializer, doing all the 
read/write formatting as well as serial-to-parallel 
and vice versa data conversion in combination with 
error detection and correction. 

Combining these chips as required allows the construction of a 
very flexible controller, supporting most of the existing con- 
troller-to-drive interface standards. 

A very usefull feature of the formatter chip is its possession 
of a 16 bit wide databus to the host computer, thus allowing a 
16 bit microprocessor to interface to the controller. Using a 
8089 I/O-processor, 1.25 Mbyte/sec can be transferred between 
the host and the controller under DMA. The controller itself 
supports transfer rates to and from the drive at a speed of up 
to 30 Mbit/sec. 

C . 5 . Siiiranary . 

Based on the little information that is available about the 
forementioned components, one can say that it is very cost ef- 
fective to integrate them in ajiy modern Winchester controller 
design. It may be considered too soon but judging from the 
above description, one might consider the National Chipset as 
one of the better choices. Unfortunately, no technical informa- 
tion is available on it yet. 
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Appendix D. CONTROLLER MODULE INTERFACE. 



D.l. Introduction. 

The interface hardware between the MSC 9000 controller module 
and the processor system was described in chapter 4 of this 
report . From the circuit diagram shown in Appendix A, one can 
see that this traditionail way of connencting a peripheral to a 
processor system results in a circuit consisting of several 
Flip-Flops and logic gates. Furthermore, the design of a cir- 
cuit like the one shown, is rather heuristic, starting out from 
timing diagrams which show the required sequence of events. 
In this Appendix, an alternative is described using a Field 
progranrmable Logic Sequencer (FPLS) to obtain a "clean", 
straight-forward design method, resulting in a functional cir- 
cuit with fewer chips. 



D.2. Interfacing to a peripheral. 

Figure D.l. below shows a generally applicable blockdiagreun of 
an interface between a peripheral and a processor or processor 
system . 



processor 




data 
transceiver 


— ^ 


peripheral 


1 > 












^ 


cont rol 
logic 


? 

s 











Figure D.l: Processor peripheral interface. 

Traditionally, the block designated by "control logic" is built 
with random logic circuitry. Depending on the complexity of the 
interface, various chips are required, often not fully used. 
The object of this FPLS approach, is to implement this control 
logic block in one FPLS. This would result in a circuit diagram 
which is almost identical to the block diagram in figure D.l. 
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\i trans 



processor 



syst e m 



isceiver 



V- 



c=c> 



FPLS 



c 



MSG 9000 

cent roller 
mod ul e 



Figure D . 2 : FPLS based interface . 



One important feature of a programmable logic control section 
should be stressed. A FPLS is a synchronous device and thus 
requires a clock signal to control its operation. Replacing a 
pulsed mode, asynchronous interface circuitry like the one 
shown in Appendix A will therefore have to be clocked at a rate 
high enough to avoid delay's compared to the asynchronous solu- 
tion. In this particular case where controller module and pro- 
cessor system each have different clocks, the clock frequency 
of the FPLS will have to exceed both of them. Since both con- 
troller module and processor system only monitor their inter- 
face signals at a minimal interval determined by their clock 
periods, the maximal delay possibly introduced by a FPLS clock- 
ed at a higher frequency would be equal to the clock period of 
either the processor clock or the module clock. 
Finally, a asynchronous circuitry has a delay caused by the ac- 
cumulated propagation delay times of the gates invloved which 
is usually in the order of 60 nsec. If the FPLS were to be 
clocked at a frequency of 16 MHz, the same result would be ob- 
tained . 

The PLO (phase locked oscillator) output, present on the 8284A 
clock generator of the processor system can be used convenient- 
ly for this purpose. Its frequency of 15 MHz will result in 
state transitions of the FPLS at 66 nsec intervals leading to 
an average delay of 33 nsec. 



D.3. Field Programmable Logic. 

Field programmable logic devices were designed to avoid the 
need of random logic often required to interface between advan- 
ced, highly complex functional modules. These non-trivial zan- 



150 



dom logic configurations rely heaviliy on small and medium 
scale integrated logic circuits, whose fixed functions lead to 
relatively high chip counts. 

Signetics corporation offers a range of field programmable 
logic chips, ranging in complexity from FPLG" s (Field Program- 
mable Logic Gate), FPIA's (Field Programmable Logic Array) to 
FPLS (Field Programmable Logic Sequencer). The table below 
outlines this product line along with some of its features . 



FIELD-PROGRAMMABLE LOGIC FAMILY 







c 
o 








lU 

« 




X 


> 




Oevica 




Organizati 


Device 


Inputs 


Outputs'" 


Chip enab 


1 

(J 
(J 


Delay (ma 


Auailabili) 


'8. 

(0 

U 
(0 

a. 


FPGA 




ANO/NANO 


82S102 
82S103 




9 OC 
9 TS 


yes 




3S ns 


now 


U 


FPLA 


• 


ANO-OR/ 
NQR 


32S100 
32S101 




8TS 
8 0C 




SOni 


now 


N, F 


• 


AND-OR 


823106 




8 0C 














• 


Sal(-<nabl> 
output 


82SI07 


16 


8TS 


nu 


170 


70 ns 


4Q79 


N 




• 


AND-Ofl 


82S104 








mA 










• 


Complenwnt 
array 


82S105 




sac 












FPLS 


• 
• 


6-btt statt 
raginer 

B-bit output 
ngiftar 






8TS 






90 nt 


4079 


N. F 



"'OC ' opancoilictor TS - three-stata 

'^'N 'Plastic F =Cerdip 

"'CE input may be optionally programmed as prasst. 



Table D.l. 

These gate arrays provide a powerful alternative to random 
logic, enabling systematic design, yielding power-, cost- and 
PC board area savings. 



FPLS description. 

For the problem at hand we will focus on FPLS's, the most 
powerful member of the gate array family. Basically, a FPLS is 
a state machine, performing synchronously clocked logic sequen- 
ces, state machines are known in two forms; 

-Moore Machines, in which the output is a function of 

the present state only. 
-Mealy Machines, in which the output is a function of 

both the present state and the present input. 
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clock 



Inpu t 



Figure D.3. shows the basic architecture of a FPLS, 



state 
register 





preset 



combinational 
logic 



< — 




output 
register 


F 



P present state 
N next state 

F next output 



Figure D . 3 : MEMiY machine . 



preset 



-> Output 



With a FPLS, any logic sequence that can be expressed as a se- 
ries of transitions between states, triggered by a valid input 
condition at clock time T can be programmed . The number of sta- 
tes involved depends on the complexity of the process involved 
and is limited by the width of the FPLS state register. In the 
case of a 82S105 FPLS, the state register is 6 bits wide so 64 
different states can be defined. Expansion of the state regis- 
ter by assigning part of the output register for this purpose 
is possible at the cost of loosing input and output lines. 
The maximum number of transitions is limited by the amounth of 
AND gates in the AND array of the FPLS, in this case 48. 

Figure D.4. shows a typical state diagram. The state from which 
the transition occurs is called the present state P, that at 
which it terminates is refered to as next state N. A transition 
allways causes a change in state but not necessarily a change 
in the machines output F. 



T„ = I ■ I ■ P 



Figure D.4: State diagram. 
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All States are aurbitrarily assigned and stored in the state 
register which has the next state information from the combina- 
tional network as its inputs, state transitions can only occur 
when the AND function of clock, present state and input condi- 
tion is true. Figure D,5. shows the architecture of a FPLS. 



lo 



-f — 

Z I _ — 



a 1 



LCLOCK 

Q S CJ- 

L-CLOCK 







PROGRAM/ 
OUTPUT- 
ENABLE 
INPUT 



-Of 



OUTPUTS 
— fo 



CLOCK 



-O-fsT 



b— ♦ F 

I — ENAI 



ENABLE 



-CLOCK 



Figure D.5: FPLS aurchitecture . 



FPLS programming. 

Programming of a FPLS can be done by means of a logic program- 
ming equipment, similar to a PROM programmer. The input connec- 
tions necessary to implement the desired logic function aire 
coded directly from the state diagram using a prograiraaing table 
as shown in figure D.7. In this table, the logic state or ac- 
tion of control variables C,I,P,N and F associated with each 
transition term Tn, is assigned a symbol which results in the 
proper fusing pattern of the corresponding link pairs. In the 
next section, an example of this state table will be shown for 
the interface function at hand. 



LIT: Electronics, July 5, 1979 pg 89-102. 
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D.4. Design. 



Designing the interface between controller module and processor 
system using a FPLS, is now basically reduced to programming 
the FPLS in the correct way. In order to do this, a state dia- 
gram is drawn, reflecting the different states in which the 
interface logic can be, as well as the input conditions that 
cause a state transition and the output status of the FPLS re- 
sulting from the transition. Refer to figure D.6. 

In order to be able to draw this diagram, two things are re- 
quired : 

1. Flow chart or Time diagram, showing the protocol 
of the communication. 

2. List of input and output signals involved. 

Time diagrams are obtained from the data-sheets supplied by the 
manufacturer of the peripheral, in this case, refer to Appendix 
B. From these time diagrams, the correct sequence of events can 
be deduced. 

Below, a list of the signal lines involved along with a block 
diagram of the interface set-up is given. 



PROCESSOR 
SYSTEM 



0=> 



MODBSY 



CMDREQ 



DRQ 1 



CMDSGN 



ACK 



PLO 



□ ATA 

TRANS 

CEIVER 



EI 



c=:> 



CKO 



FPLS 



ck 



RDY 



LDl 



□OUT 



BUSY 



CLR 



CMP 
STROBE 



MSG 9000 



Figure D.8: Signal lines. 
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FPLS input signals. 

CMDSGN: Issues a command cycle start request to the 

controller . 
ACK ! Acknowledge data transfer. 
RDY : Controller ready to accept or sent data. 
LDI : Data input request. 
DOUT : Data output recpiest. 
BUSY : Controller busy. 
CLR : Reset interface. 



FPLS output signals. 

MODBSY: Module busy indication. 

CMDREQ! Command byte request to processor system. 
DRQl : DMA request signal. 
EI : Enable input latch. 
CKO : Clock output latch. 

CMD : Signal command cycle start to controller mo- 
dule. 

STBDBE: Data transfer strobe signal. 



The input- and output vectors for the state diagram shown in 
figure D.6. are as follows: 

I: RDY LDI DOOT BUSY CMDSGN ACK CLR 
16 15 14 13 12 II 10 

O: CMDREQ MODBSY DRQl CMD STROBE EI CKO 
F6 F5 F4 F3 F2 PI FO 



The format used at the state transition arrows is: 

16 15 14 13 12 II 10 / P6 P5 P4 P3 P2 PI PC 
INPUT CONDITION OUTPUT RESULT 



Appearantly, the total number of states involved is 13, thus 
only four bits of the state register are needed. Coding of 
these states can be done arbitrarilly so the binairy equivalent 
of the state numbers shown in figure D.6 waus taken. Figure D.7. 
shows the corresponding programming sheet . 



Once the FPLS has been programmed, the hardware of the inter- 
face between the MSC 9000 controller module and the processor 
system will look as is shown by Figure D.9. The difference with 
the corresponding circuit diagram of Appendix A is obvious. 
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S8 




SI 
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J2: 0010111/1000010 



S3 



3 module 
ready for 
cmd byte 



S4 



T3: 0019101/1000109 



n3--0018111/100001B 



data i/o 
mode 



TA:0110111/0000f 
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STATE DIAGRAM 
D 6 



S8 

^8:0111111/0101 010 
T9: 1110111/0001010 



BIPOLAR MEMORY DIVISION 



MAY 1981 



FIELD PROGRAMMABLE LOGIC SEQUENCER 



82S104 (O.C.)/82S105 (IS.) 



INTEGRATED FUSE LOGIC 
SERIES 28 



FPLS PROGRAM TABLE (Logic) 



CUSTOMER NAME . 



PURCHASE ORDER # . 
SIGNETICS DEVICE # . 



TOTAL NUMBER OF PARTS . 
PROGRAM TABLE # 



.REV. 



. DATE . 



THIS PORTION TO BE COMPLETED BY SIGNETICS 

CF (XXXX) 

CUSTOMER SYMBOLIZED PART # 

DATE RECEIVED 

COMMENTS 



PROGRAM TABLE ENTRIES: 
Cn Im, P« 


N*. Fr 


P/E 
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NOTES 

1. The FPL§ is shipped with all links initially intact. Thus, a background of "0" tor all 
Terms, and an "H" for the P/E option, exists in the table, shown BLANK instead for 

clarity. 

2. Unused C^. 'm- ^s ^''^ ^'^ normally programmed Don't Care (— ). 

3. Unused tranaiiion and output Terms can be left blank. 

4. Letters in variable fields are used as identifiers by logic type programmers. 
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